On Wed, May 27, 2009 at 12:50:59PM -0400, Greg Hudson wrote:
> As a matter of history, I've not been impressed with application-level
> hardcoded timeouts, so I didn't put any into ra_svn. It's not the case,
> as you said in #3347, that I explicitly removed some default timeout
> present in APR or the operating system; those layers don't have default
> timeouts.
>
> What I would recommend to address #3347 is setting the SO_KEEPALIVE flag
> on the socket, which will cause the underlying TCP layer to use
> keepalive packets to eventually notice when the other half of the
> network connection has disappeared without sending a reset. I'm not
> sure how to do that through APR, but it's probably not too difficult.
OK, so I've tried to educate myself a bit.
I'm not really sure whether we should use TCP keep-alives.
They're an extension to TCP, though I'd suspect most operating systems
would support them these days. But RFC1122 states:
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.
This does not apply to our sitation. We're not a server, we're
a client behind a NAT. Granted, RFC1122 dates from 1989 so
NAT wasn't even invented yet :) RFC1631 was written in 1994.
Still, could you explain more precisely why you would not want us
to timeout after some predefined amount of time? Because that is
really easy to do and is guaranteed to work on any TCP implementation,
even if it does not feature keep-alives. If we can agree on a reasonable
timeout which is likely to indicate problems, say, 2 hours, why not
just do it? I can't think of any reason why an svn connection stalled
for 2 hours or more should not have to be restarted.
Thanks,
Stefan
Received on 2009-05-27 21:23:29 CEST