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

Re: (ITS#4783) ldap_sasl_bind() is not asynchronous

On December 28, 2006 10:06:40 AM +0100 Pierangelo Masarati 
<ando@sys-net.it> wrote:
> Frank Cusack wrote:
>> Oh, in that case I am definitely missing a lot.  Since my understanding
>> of the timeout value passed to ldap_sasl_bind() is that it is a *bind*
>> timeout, which I assumed would be because some artibrary SASL mechanism
>> might take some arbitrarily long amount of time.  If there is no bind
>> timeout, then why is LDAP_OPT_NETWORK_TIMEOUT implemented?  The timeout
>> passed to ldap_sasl_bind() should just be the connect() timeout then.
> ldap_sasl_bind() cannot be passed any timeout.  What timeout are you
> referring to?

grrr ... I would have sworn there was a timeout arg!  I must have
confused it with ldap_search().  The Netscape API does not have a
timeout arg either.  I'd implemented my thread wrapper (w/ timeout)
before I learned of the LDAP_OPT_NETWORK_TIMEOUT option
(LDAP_X_OPT_CONNECT_TIMEOUT for Netscape API).  I guess when I found
that option, I falsely remembered that ldap_sasl_bind_s() had a
timeout arg.

> I must disagree with the above.  As far as I understand.
> LDAP_OPT_NETWORK_TIMEOUT does what you expect: it makes connect() time
> out as required.  ldap_sasl_bind() should return as soon as the packet
> with the request has been sent, and the rest of the timeout policy for
> the bind only part should be dealt with by the client using the
> ldap_result() timeout arg as appropriate.  I've recently tested that
> behavior for customers who wanted some certain timelimit on all
> operations, not just searches, and that required some extensive
> modifications to the proxy backends, but the client library (libldap) was
> not touched at all.  In that case, the code basically uses
> ldap_sasl_bind() to wrap simple binds (that's what the proxy backends
> mostly do), and using LDAP_OPT_NETWORK_TIMEOUT makes it work as expected.
> I can't speak for truly SASL bind as I didn't experiment timeouts with
> that.

Sounds right.  In the case of a truly SASL bind where there might be a
long delay, async ldap_sasl_bind() should be enough.

Thanks for your patience.