On Wed, May 27, 2009 at 04:24:24PM -0400, Greg Hudson wrote:
> On Wed, 2009-05-27 at 20:23 +0100, Stefan Sperling wrote:
> > A TCP keep-alive mechanism should only be invoked in
> > server applications that might otherwise hang
> > indefinitely and consume resources unnecessarily if a
> > client crashes or aborts a connection during a network
> > failure.
> That RFC is paranoid about saturating links with unnecessary keepalive
> requests, which is an outdated concern.
> I'm confident that every TCP implementation supports keepalives.
> > Still, could you explain more precisely why you would not want us
> > to timeout after some predefined amount of time?
> Just because we don't have a bound on how long each operation should
> take. If the other side is present and responding to keepalives, then
> either (1) it's still working, or (2) we have a bug and the protocol got
> deadlocked. In the first case, we shouldn't time out; in the second
> case, timeouts are a poor workaround for bugs.
Right. So we would be using keep-alives as an out-of-band mechanism,
in the sense that we ask TCP to please tell us if we get a reset from
the other side when sending non-svn-protocol messages. The svn protocol
itself is then isolated from having to deal with this network-layer
I see your point and will try to find a way to do this.
Received on 2009-05-27 23:34:33 CEST