Re: tcp timeoutcon patch for libldap

[Lars Uffmann <lars.uffmann@mediaways.net>]

"Kurt D. Zeilenga" wrote:
> 
> At 02:59 PM 7/28/99 +0200, Lars Uffmann wrote:
> >we had massive problems with LDAP clients
> >blocking in the connect() system call.
> >So I wrote a patch against libldap/os-ip.c
> >which uses a non-blocking socket and select()
> >to avoid this.
> 
> One of the issues we need to discuss is where
> handling of such I/O details is to be done.  I
> see a bit of discontinuity between this change
> and recent TLS changes which moved some of the
> I/O option handling down into -llber.
> 
> It's my opinion that I/O options should be
> set by -lldap (through LDAP_OPT_ mechanism) and
> passed down into -llber.  -llber should be
> designed to work read/write from any I/O channel
> and that the caller should provide replacement
> routines (via hooks) if the default (read/write)
> are not appropriate (such as for TLS).

This is how netscape/mozilla does it.
The caller can supply function hooks via
ldap_set_option/LDAP_OPT_.

> 
> Applications which use -llber directly (such as
> slapd) would have to manage the I/O options
> internally.  This, of course, can be facilated
> by exposing a private interface to -lldap routines
> to do the nitty gritty.
> 
> Anyways, as the TLS developers have obviously
> put some thought into the changes they introduced,
> I think it wise of them to examine your patch
> and offer comments on how best to proceed.

This sounds like we should look for an  I/O
abstraction layer in llber. For my particular problem,
the posibility to provide a custom connect() function
via ldap_set_option, would have solved the problem. 

> 
> >To set/get the timeout, I used
> >the yet unused LDAP_OPT_TIMEOUT option flag
> >in ldap.h.
> 
> The LDAP_OPT_TIMEOUT was meant to be used as a
> per LDAP API call timeout versus a per network call
> timeout.  Implementation of such gets a little
> tricky.

Per API call timeouts is a differrent story ...
I think the API specs are quite inconsistent. For example,
there is no ldap_bind_st() api function.
But we solved this by writing a custom bind_st() function.
The only issue left is the bind call when following
referrals. Do you have any suggestions how to get arround this?
Maybee LDAP_OPT_TIMEOUT could be used here.

> 
> If you want a per network call timeout, I would
> suggest introducing another option.
>         LDAP_OPT_NETWORK_TIMEOUT
> 

If you are willing to include my patch / provide the
timeoutconnect feature (either way) I would be happy
code this.

> Enforcing both is a little tricky, but doable.
> 
> Note: The invalue of these options should be
> "struct timeval *".

I can correct this, if you think it is important.


regards, Lars