[Date Prev][Date Next]
Re: tcp timeoutcon patch for libldap
"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
> 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
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.
If you are willing to include my patch / provide the
timeoutconnect feature (either way) I would be happy
> 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.