[Date Prev][Date Next]
Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
On December 28, 2006 9:34:36 AM +0100 Pierangelo Masarati <firstname.lastname@example.org>
> email@example.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
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.