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

[ando@sys-net.it]

fcusack@fcusack.com wrote:
> Unfortunately I won't be able to contribute a patch as I've worked
> around it in my application (I created a separate thread to handle
> the ldap connect) so I can't afford to invest the time.  Plus I needed
> a solution that would work with the Netscape API as well as OpenLDAP.
>
> 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.  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.  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.

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
------------------------------------------