On Mon, Jun 21, 2010 at 12:42 AM, Florian Pflug <fgp@phlo.org> wrote:
> I'd buy that if all timeouts and retry counts would default to +infinity. But they don't, and hence sufficiently long
networkoutages *will* cause connection aborts anyway. That a particular connection might survive due to inactivity
provesnothing, since whether the connection is active or inactive during an outage is usually outside of anyone's
control.
>
> I really fail to see why anyone would prefer connections (and therefore transactions!) getting stuck forever over a
fewspurious disconnects. The former always require manual intervention and cause all sorts of performance and
disk-spaceissues, while the latter won't even be an issue for well-written clients who just reconnect and retry.
>
So just as a data point I'm routinely annoyed by reopening my screen
session and finding various session sessions have died since the day
before. Usually this is caused by broken firewalls but there are also
a bunch of SSH options which some servers have enabled which cause my
sessions to never survive very long if there are any network outages.
Servers where those options are disabled work fine.
I admit this is a very different use case though and since we have
control over the behaviour when the connection breaks perhaps the
analogy falls apart completely. I'm not sure we can guarantee that
reconnecting is always so simple though. What if the user set up an
SSH gateway or needs some extra authentication to make the connection.
Are users expecting the slave to randomly disconnect and reconnect
willy nilly or are they expecting that once it connects it'll keep
using that connection forever?
--
greg
