Re: tcp timeoutcon patch for libldap

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

"Kurt D. Zeilenga" wrote:
> 
>
> 
> Or use a client control with with ldap_*_ext_s().
> The _st() routines, in my option, should be deprecated.
> 
> >The only issue left is the bind call when following
> >referrals. Do you have any suggestions how to get arround this?
> 
> If a API timeout was specified, the time spent obtaining
> the referral must be substracted from timeout used
> in the chasing request.
> 
> >Maybee LDAP_OPT_TIMEOUT could be used here.

Couldn't LDAP_OPT_TIMEOUT be used by ldap_result() whenever
the struct timeval * arg is NULL ? This would asure that no
single API call would block more then tv_sec seconds. Default
behaviour wouldn't change at all (LDAP_OPT_TIMEOUT == NULL).

> 
> Actually, my point about using controls brings up an
> another possibility.  A default client control could
> (and maybe should) be used instead of LDAP_OPT_TIMEOUT.
> 
> >> 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.
> 
> This, too, could be handled by a client control...

I still havn't dealt with client/server ontrols.
Seems like it's time to give it a try.

> (but an opt is fine for now).
> 
> >> Note: The invalue of these options should be
> >> "struct timeval *".
> >
> >I can correct this, if you think it is important.
> 
> For now, can you resubmit (as an ITS) using
> LDAP_OPT_NETWORK_TIMEOUT and struct timeval *
> (be sure duplicate the structure in and out of
> ldap_set/get_option).

Ok, will be done today.

> 
> We'll also should to sort out configure issues
> surrounding inet_aton() and O_NDELAY...

the inet_aton() check shouldn't be too hard, and the
O_NDELAY stuff goes to ac/socket.h. That's Ok?

-- lars