Following on from ITS#5133, there are a couple different scenarios to deal with...
1) the remote network segment has disappeared (or the remote server has
2) an intervening firewall has killed the connection
Neither case is really distinguishable from the consumer side. In the case of
a hardware failure, where either the remote host or the network to the host
has failed, there's little to be gained by setting an aggressive retry policy.
Failures of that sort tend to take a non-trivial amount of time to repair.
I've seen some app guides recommending keepalives be sent once a minute or so;
to me that is way overdoing things.
In the case of a firewall closing an idle connection, you really have to ask
yourself what you're trying to accomplish - are you trying to send probes
frequently enough to prevent the connection from closing, or are you just
trying to detect that it has closed? This may be giving too much credit to the
firewall admins, but I'd guess that they've set an idle timeout that is
appropriate for the load that their networks see. Artificially inflating
traffic on a connection to prevent it from appearing idle would just be an
abuse of network resources. It's also possible that a stateful firewall will
start dropping connections because it's been overwhelmed by traffic, and
simply doesn't have the memory to track all the live connections. Keeping the
connection open in these circumstances would just make a bad situation worse.
As such, it seems to me that you don't really want to be setting very short
keepalive timeouts anywhere. The default of 2 hours that most systems use
seems pretty reasonable.
On the other hand, it would probably be useful to be able to prod the consumer
and have it kick the connection on request. In the past I've implemented this
sort of thing using Search requests with magic filters. I.e., treat the Search
operation as an RPC call, the target object is simply an embedded method, and
the AVAs in the filter comprise a named parameter list.
So e.g. one might do a search on "cn=Sync Consumers,cn=monitor" with filter
(|(objectclass=*)(kick=TRUE)) to cause every active consumer to probe its
I like this approach a lot better than Modifying an object, because you can
hit many objects at once with a Search request, and receive all of their
execution results as attributes of the returned entries.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/