RE: draft-ietf-ldapext-ldap-c-api-03 & timeout

[Howard Chu <hyc@highlandsun.com>]

> -----Original Message-----
> From: Harald Tveit Alvestrand [mailto:Harald@Alvestrand.no]

> At 19:05 28.09.99 -0700, fan jiao wrote:
> >I agree the simple timeout has less
> >complexity to manage. But it doesn't
> >work well in a congested production
> >network. On the other hand, the
> >exponential timeout is being widely used
> >in SNMP world; it has been proven to
> >increase odds to retry/re-connect to
> >network devices.
>
> remember that the LDAP timeout is occuring on top of a TCP connection.
> Retransmissions to correct for network troubles occur on the TCP level,
> and already use exponential backoff.
>
> Retransmissions on the LDAP level (if they make sense) will have to be
> done if the *server* is congested - and can only make sense if the server
> is written in such a way that it can lose a request without losing the
> connection - something that seems a bit strange to me.
>
> I don't think LDAP should do retransmission; if it did, it would
> have to be of the "assume stalled engine, tear down connection and
> try again on a new connection" variety.
>
> Someone tell me if I'm in the wrong garden....

Certainly the initial question wasn't very clear, but I don't believe
network congestion is the issue. I interpreted this to be more along
the lines of clients with long-lived sessions. One commonly available
LDAP graphical browser has an annoying feature that if the server to
which the browser is connected goes down, the browser does not recognize
the LDAP_SERVER_DOWN error status. As such, you have to manually close
the LDAP session in the browser. If the server was simply killed and
restarted, you won't know what really happened until you manually try
to re-connect.

Since the original message talked about exponential timeout on the
bind request, I would assume it's related to this problem of when/how
to re-connect to a dropped server connection. I'm not sure this is really
something that the present LDAP API should address, but I guess it would
be a nice feature to have standardized.

If the client in question is itself some other server, and not being
directly driven by a human, the question becomes more interesting - how
often do you attempt to re-connect to a dead server? When do you give up
completely? The exponential timeout is probably a good approach for this
problem.