"Oliver Jowett" <oliver@opencloud.com> writes:
> For the environment I'm running in, network congestion sufficient to drop
> multiple keepalive packets is equivalent to server failure anyway.
Well, it could just mean someone is doing an ftp transfer and you got unlucky
with which packets got dropped.
> 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.
Well you don't just "hear about" it. You get your connection reset.
Effectively you guarantee that there are network problems even if there
weren't really problems before.
The worst offender on this front is SSH. Whenever my DSL modem reboots or my
wireless modem gets interference my SSH connections often hang and I have to
reconnect. I think this is actually due to the application-level keep-alives
that SSH is doing, not TCP keep-alives, but it's the same principle. SSH
turned an situation where no error was necessary into an error that required
manual recovery.
The various instant messenger systems are also frequent offenders but at least
they have a reasonable excuse. They have to deal with millions of users on
dynamic addresses which appear and disappear without warning. If they stuck
around waiting for you to come back ten minutes later they would be waiting on
thousands of such dead connections. That's what TCP keep-alives are for, but
they're a trade-off between reliability and wasted resources. The instant
messenger systems don't put much of a premium on reliability and they can just
reconnect anyways.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!