persistent search and keepalives

[Howard Chu <hyc@symas.com>]

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 
crashed)
  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 
connections.

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/