Re: (ITS#3528) add time limit options for bind and exop requests

[Kurt@OpenLDAP.org]

Though this does absolutely nothing about SSL_Connect blocking
on an I/O, I have committed to head an async version of
ldap_start_tls_s(3) in ldap_start_tls(3) and ldap_install_tls(3).
Note here that async here means only that request and response
for the operation can be managed independently of each other,
not requiring the program to "block" on the server response.
The async API does not address I/O or other blocking issues.

I intend to close this ITS as it addresses the lack of async
version of ldap_start_tls_s(3).  I/O blocking issues should be
handled separately.

Kurt

At 02:18 PM 2/1/2005, nalin@redhat.com wrote:
>On Mon, Jan 31, 2005 at 09:08:47PM -0800, Kurt D. Zeilenga wrote:
>> > If I'm reading the code right, all bind requests
>> > and exop requests issued by libldap are allowed
>> > to block indefinitely.
>> 
>> You are not reading the code correctly.  Only ldap_*_s() functions
>> wait indefinitely for the server response (by design).  The async
>> calls, such as ldap_sasl_bind(3) and ldap_extended_operation(3), do
>> not wait for response (by design), instead the caller to obtain the
>> response(s) using ldap_result(3) (which takes a timeout parameter).
>
>You're right about that.  The problem I'm running into is that the
>client is blocking during SSL_connect() on an ldaps connection, and this
>is happening during an async call (ldap_simple_bind).  Maybe that's the
>only real problem here.
>
>> I note that there are some higher level calls which may
>> only provide sync or async APIs.  Generally, there are reasons
>> behind this.  Likely, just inserting a timeout is not the
>> complete (or proper) way of providing the desired behavior.
>> That is, likely it would be better to design, say,
>> ldap_start_tls() than to add timeouts to ldap_start_tls_s().
>
>I thought about it some more, and you're right that this can't possibly
>be the right solution.  If the server wakes up and then successfully
>executes the bind or exop request, the client won't know about it, and
>the client and server will have differing ideas about the connection
>state.
>
>Because the calls to libldap are being made in a library function
>(specifically, nss_ldap, which itself may be called from a
>multi-threaded application), I can't wrap the whole bind/search/unbind
>sequence with a SIGALRM timer and expect to never break calling
>applications.  If the calling application isn't multi-threaded, the
>bind/search/unbind sequence can't be relegated to a thread which is
>monitored and possibly killed by another thread.
>
>Other than an introducing an async start_tls exop, I can't come up with
>a way to solve this.  That would probably complicate async bind
>operations on ldaps connections, which would implicitly need to call it,
>but ldap+start_tls would become a perfectly usable alternative in that
>case.
>
>Nalin