On Tue, 8 Apr 2008, Chris Adams wrote:
On Apr 8, 2008, at 10:54 AM, Aaron Richton wrote:
> I think you might be confusing LDAP_OPT_NETWORK_TIMEOUT and
> LDAP_OPT_TIMEOUT. (Or maybe I am...) But as I recall, NETWORK_TIMEOUT is
> for initial connect(), and you're referring to ongoing conversations.
Aaron is correct that LDAP_OPT_NETWORK_TIMEOUT only affects connect() in
the released versions.
In versions before 2.4.4, LDAP_OPT_TIMEOUT had no effect. Starting in
version 2.4.4 it sets the default timeout for reading the requested
result in ldap_result().
This is correct - I'm proposing extending that to include a
timeout for all
network communication. In some cases the APIs have a timeout but many do not
and this seems cleaner than requiring the client to pass a timeout for every
call which could conceivably perform network operations.
Since all the synchronous calls (ldap_*_s) are built on top of
ldap_result(), if you set LDAP_OPT_TIMEOUT then those calls will
automatically use that value. That's the behavior you're looking for,
I understand the current situation but as a user it would feel more
for LDAP_OPT_NETWORK_TIMEOUT to mean "try the next server if a response is
not obtained within this time", covering the additional class of failures
where an LDAP server is partially up as we cannot guarantee minute-level
admin response times to restart a failing server.
Hmm, what do you think the distinction between LDAP_OPT_NETWORK_TIMEOUT
and LDAP_OPT_TIMEOUT should be? (Neither of which should be confused with
LDAP_OPT_TIMELIMIT, of course.)