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

[ando@sys-net.it]

Frank Cusack wrote:
>
> 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_sasl_bind() cannot be passed any timeout.  What timeout are you 
referring to?
>>  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.)
They are.
>
>>  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.
I must disagree with the above.  As far as I understand. 
LDAP_OPT_NETWORK_TIMEOUT does what you expect: it makes connect() time 
out as required.  ldap_sasl_bind() should return as soon as the packet 
with the request has been sent, and the rest of the timeout policy for 
the bind only part should be dealt with by the client using the 
ldap_result() timeout arg as appropriate.  I've recently tested that 
behavior for customers who wanted some certain timelimit on all 
operations, not just searches, and that required some extensive 
modifications to the proxy backends, but the client library (libldap) 
was not touched at all.  In that case, the code basically uses 
ldap_sasl_bind() to wrap simple binds (that's what the proxy backends 
mostly do), and using LDAP_OPT_NETWORK_TIMEOUT makes it work as 
expected.  I can't speak for truly SASL bind as I didn't experiment 
timeouts with that.

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office:   +39.02.23998309
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it
------------------------------------------