Gregory Stark wrote:
> The local case is precisely where you wouldn't want to use keep-alives. When
> the server does come back up you'll get RSET packets and the connections will
> die.
This does assume that the server is not down because it's caught fire..
>> Keepalive helps a little but it's certainly not perfect. I ended up doing
>> all the dead server detection at a higher level in the end.
>
> I think you're doing exactly what you have to do. You certainly don't want to
> predicate failover on simple network reachability. You want to base it on the
> application actually functioning. Network reachability is both too sensitive
> (keep-alive packets could be dropped due to congestion) and not sensitive
> enough (if the application crashes the host may still be reachable).
For the environment I'm running in, network congestion sufficient to
drop multiple keepalive packets is equivalent to server failure anyway.
Agreed that you want application-level tests anyway, it's just that if
there are network problems I would prefer to hear about them sooner
rather than later - it seems a little silly to have the information
available at the TCP level, but ignore it. You have to tune app-level
timeouts to take account of the normal response time of the app, which
might be quite different to the normal response time of the network.
-O