Re: (ITS#4783) ldap_sasl_bind() is not asynchronous

[fcusack@fcusack.com]

On December 28, 2006 9:34:36 AM +0100 Pierangelo Masarati <ando@sys-net.it> 
wrote:
> fcusack@fcusack.com wrote:
>> I did find LDAP_OPT_NETWORK_TIMEOUT, which I didn't try, but which is
>> close to the desired functionality.  AFAICT it implements a *separate*
>> timeout for the connect() (and maybe unbind/close()?) part of an ldap
>> connection.  Why someone would want to distinguish between connect()
>> and bind I don't know, especially when they don't get feedback about
>> how long connect() took.
>>
>> It should be easy (?) to add something like LDAP_OPT_CONNECT_BIND_TIMEOUT
>> which would be the total time for connect() and bind, given that
>> non-blocking connect() is already implemented.  That would probably
>> solve a lot of folk's need for a working async bind.
>>
>>
> I think you're missing a point: there's no bind timeout because there's
> no need for it.  The delay (or the hang) you likely see when dong
> ldap_sasl_bind() is actually spent doing a connect() to establish a
> connection.

Oh, in that case I am definitely missing a lot.  Since my understanding
of the timeout value passed to ldap_sasl_bind() is that it is a *bind*
timeout, which I assumed would be because some artibrary SASL mechanism
might take some arbitrarily long amount of time.  If there is no bind
timeout, then why is LDAP_OPT_NETWORK_TIMEOUT implemented?  The timeout
passed to ldap_sasl_bind() should just be the connect() timeout then.

>  ldap_initialize() doesn't actually establish any connection,
> it just sets up the handler, and the connection is established by the
> first operation that requires it.  the asynchronous bind, muck like any
> other asynchronous operation, simply returns after sending the packet(s)
> containing the request.

That much I do understand.  (Although I thought the async bind() functions
weren't actually implemented async.)

>  But, of course, the first of them requires the
> connection to be established, and that's where LDAP_OPT_NETWORK_TIMEOUT
> comes into play.  Doing a really asynchronous connect() implies returning
> some sort of LDAP_X_INPROGRESS, keeping track of the status of the
> connection and polling it for response for each subsequent call until the
> connection is established before actually sending any request.  In this
> sense the change should be intrusive: in this design, client code should
> be able to handle the LDAP_X_INPROGRESS return code and resubmit the
> request until the connection is ready.  A "smarter" design would cache
> the request, poll for connect() response during calls to ldap_result(),
> and submit the actual request when the connection is established.

Sure, I understand that also (now).

What I'm saying is that most folks probably don't really need an async
connect(), they just need a non-blocking one that returns in some known
amount of time.  LDAP_OPT_NETWORK_TIMEOUT doesn't do that, since it
only controls the connect() part, and not the subsequent bind (important
since you can only get to connect() via the ldap_bind() or other calls, ie
there is no ldap_connect() and ldap_open() is deprecated).  But a new
LDAP_OPT_CONNECT_BIND_TIMEOUT option could do it.

-frank