[Date Prev][Date Next] [Chronological] [Thread] [Top]

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.

  Dave Steck

>>> Lars Uffmann <lu@mediaways.net> 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?