On December 28, 2006 10:06:40 AM +0100 Pierangelo Masarati
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
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
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
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.