[Date Prev][Date Next]
Re: tcp timeoutcon patch for libldap
"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
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?