On December 22, 2006 10:56:40 AM +0100 Pierangelo Masarati ando@sys-net.it wrote:
fcusack@fcusack.com wrote:
But still you can do the bind async, and just close the fd on the client side on timeout. I don't see why connect() timeout can't be handled the same way. (ignoring the problem that there is no API call AFAICT to just drop the connection)
I'll note that there's been some interest in that area --- I loosely have the same need (see http://www.openldap.org/lists/openldap-devel/200611/msg00000.html) but unfortunately it's not in my priority list, considering that it might have relevant impact on the client library.
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.
-frank