Re: proposal: setKeepAlive

Gregory Stark wrote:
> "Oliver Jowett" <oliver(at)opencloud(dot)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.

Not on the dedicated cluster interconnect LAN they're not.

>> 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.

You are talking about a WAN environment where you have a user at the
helm and a high tolerance for unexpected and potentially large latency
spikes.

I agree that aggressive keepalives are not particularly useful in that case.

However, this is not the only possible environment. In some environments
you WANT any significant deviation from normal network operation to be
noticed at the application level, so you can automatically fail over to
your redundant server rather than try to soldier on with failing equipment..

-O