[Date Prev][Date Next]
Re: problem with blocking ldap_bind
We struggled with this same problem. We saw that the initial connect
hung at the socket level, and we saw no way to specify the
OPT_NETWORK_TIMEOUT in the socket connect() function. The socket
eventually does timeout, but this timeout is platform-dependent. On
Windows, for example, it's set by some parameters in the registry.
We modified the initial connection procedure by:
1. Calling ioctl() and setting the socket to non-blocking mode
2. Doing the connect(), which returns EWOULDBLOCK or EINPROGRESS -
you must test or both of them.
3. Doing a select() call with the OPT_NETWORK_TIMEOUT
4. Setting the socket back to blocking mode.
The socket framework we're using at Novell is much different than
OpenLDAP's so I can't just check changes back in, but this approach
works for us.
>>> Lars Uffmann <firstname.lastname@example.org> 07/16/02 05:36AM >>>
On Tue, Jul 16, 2002 at 12:58:49PM +0200, Helmut Lehner wrote:
> But ldap_bind still blocks too long for our purpose if there is no
> to the LDAP-server, for example.
Hmm, thats what I implemented OPT_NETWORK_TIMEOUT for. If you use
ldap_init(), the actual TCP connect() will be delayd until the first
operation, ie ldap_bind(). Connect _schould_ return after the timeout
specified with ldap_set_option. You may send a truss output?
It schould work like this:
LDAP_OPT_NETWORK_TIMEOUT implements a non-blocking connect.
The timeout you pass to ldap_result is the maximum amount of time to
wait for the next ldap response, if the session is allready
> LDAP_OPT_NETWORK_TIMEOUT specifies the maximum time to wait to
> > the TCP connection to the ldap server.
> I also set the LDAP_OPT_NETWORK_TIMEOUT and ldap_bind hangs for a
> (longer as specified in LDAP_OPT_NETWORK_TIMEOUT).
> Is there maybe another option i have to set, so that the call is
> interrupted after a configurable time?