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

Thursday, 28 December 2006

On December 28, 2006 9:34:36 AM +0100 Pierangelo Masarati <ando(a)sys-net.it&gt; 
wrote:
...
 fcusack(a)fcusack.com wrote:
> I did find LDAP_OPT_NETWORK_TIMEOUT, which I didn't try, but which is
> close to the desired functionality.  AFAICT it implements a *separate*
> timeout for the connect() (and maybe unbind/close()?) part of an ldap
> connection.  Why someone would want to distinguish between connect()
> and bind I don't know, especially when they don't get feedback about
> how long connect() took.
>
> It should be easy (?) to add something like LDAP_OPT_CONNECT_BIND_TIMEOUT
> which would be the total time for connect() and bind, given that
> non-blocking connect() is already implemented.  That would probably
> solve a lot of folk's need for a working async bind.
>
>
 I think you're missing a point: there's no bind timeout because there's
 no need for it.  The delay (or the hang) you likely see when dong
 ldap_sasl_bind() is actually spent doing a connect() to establish a
 connection. 
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_initialize() doesn't actually establish any connection,
 it just sets up the handler, and the connection is established by the
 first operation that requires it.  the asynchronous bind, muck like any
 other asynchronous operation, simply returns after sending the packet(s)
 containing the request. 
That much I do understand.  (Although I thought the async bind() functions
weren't actually implemented async.)

...
  But, of course, the first of them requires the
 connection to be established, and that's where LDAP_OPT_NETWORK_TIMEOUT
 comes into play.  Doing a really asynchronous connect() implies returning
 some sort of LDAP_X_INPROGRESS, keeping track of the status of the
 connection and polling it for response for each subsequent call until the
 connection is established before actually sending any request.  In this
 sense the change should be intrusive: in this design, client code should
 be able to handle the LDAP_X_INPROGRESS return code and resubmit the
 request until the connection is ready.  A "smarter" design would cache
 the request, poll for connect() response during calls to ldap_result(),
 and submit the actual request when the connection is established. 
Sure, I understand that also (now).

What I'm saying is that most folks probably don't really need an async
connect(), they just need a non-blocking one that returns in some known
amount of time.  LDAP_OPT_NETWORK_TIMEOUT doesn't do that, since it
only controls the connect() part, and not the subsequent bind (important
since you can only get to connect() via the ldap_bind() or other calls, ie
there is no ldap_connect() and ldap_open() is deprecated).  But a new
LDAP_OPT_CONNECT_BIND_TIMEOUT option could do it.

-frank

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006