Re: idletimeout (was: openldap client connect limit)

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Quanah Gibson-Mount writes:
>--On Tuesday, April 26, 2005 10:20 PM +0200 Hallvard B Furuseth
><h.b.furuseth@usit.uio.no> wrote:
>
>> Another wish: Ability to exempt a few IP-addresses, bound DNs
>> etc. from idletimeout.  I'd like to tune our idletimeout _way_ down,
>> but currently that would break our MTA.  Not a good idea:-)
>
> Any client that uses persistent connections and doesn't understand how
> to rebind after getting disconnected is fundamentally flawed.

Sure, but it happens anyway.

<rant>

Frankly, I don't blame them.  The library returns LDAP_SERVER_DOWN both
for a failed connect attempt and a lost connection.  I think that goes
all the way back to Umich LDAP.  Not only is the name misleading, but
the client has to keep track of whether or not the failed operation was
the first operation on the connection or not.  If yes, the server is
probably down.  If no, it should reconnect.  Or it can send a Bind
(maybe anonymously) at once after ldap_init() just so that it can test
if the server is down without keeping track of previous operations.  Why
isn't there a call which just opens the connection?  I don't think the
library provides a hook to automatically reconnect either, but I'm not
sure.

I do wish for a reconnect hook, but I seem to remember that originally
existed and was removed for some reason.

Also I'd like to exorcise the LDAP_SERVER_DOWN code from the face of the
Earth and replace it with two result codes.  But maybe that'll have to
wait for the entire API to be replaced.  Just introducing one new result
code would break all the clients that handle today's LDAP_SERVER_DOWN
correctly.

</rant>

I guess someone really ought to get at the task of designing a new API.
Easy to say, of course, when I won't have time to be one of the
"someones" in the forseeable future...

-- 
Hallvard