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

[nalin@redhat.com]

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