kfogel@collab.net wrote:
>Auke Jilderda <auke.jilderda@philips.com> writes:
>
>
>>Trying to use Subversion at a fairly large project, we repeatedly run into
>>some networking issues, causing SVN to bail out with error messages such
>>as: "Could not read response body: An existing connection was forcibly
>>closed by the remote host." and "Could not create SSL connection through
>>proxy server". We suspect it might be our corporate proxy server
>>infrastructure that might be causing this but we have yet to track down
>>the precise cause.
>>
>>In any case, it raises an interesting issue: Apparently, Subversion does
>>not try to re-connect a busted network connection and I'm wondering why
>>that is? Being a networked application that often needs an open
>>connection for a prolonged amount of time (e.g. we've seen commits that
>>take over two hours), it might be wise to provide some sort of graceful
>>degradation (e.g. trying once or twice to restore a broken connection
>>before bailing out). Any arguments in favour or against this?
>>
>>
>
>I feel a little uncomfortable making Subversion take on
>responsibilities that should belong to the transport layer. Wasn't
>TCP supposed to take care of this stuff for us? If it's not, can we
>realistically do much better?
>
>
>
TCP is designed to account for packet loss and has generalized
algorithms with corresponding parameters to accomplish this, but it is
quite generic. As well, it is purely for maintaining a communication
session from a networking point of view. There are certainly cases
where from a TCP point of view is has exhausted its algorithms and as
such the communication session gets killed (either from the POV of the
client or the server TCP stack, or both) but from an application
session POV, if another TCP connection can be established, it makes
sense to not abandon the application session (and all the application
state, both server & client) so that they can continue on a new TCP
connection.
I've worked with a product (Tivoli Storage Manager, which coincidentally
does versioned backups) whose backup/archive client will try to
re-establish sessions with the server if the original TCP session dies
and pick up where it left off; it actually maps its sessions to TCP
connections and simply allows a client operation to continue by creating
a new application session on top of a new TCP connection. When you have
experienced that re-connect at the application layer, you really
appreciate it.
As Auke says, with a 2 hour application operations, it would be nice if
a short network interruption (which is sufficient to break a TCP
connection) would not lose the much longer-lived operation.
Anyway, it would be a large undertaking. My point is that there are
valid reasons for there being additional failure handing above the
network connection layer, or to put it the other way, TCP gives you a
very low level of failure recovery, but certainly not good enough for
every case.
Cheers...
Bruce
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 29 21:41:10 2004