Bob ...
Therein lies the fundamental problem:
At an application layer of the OSI model, SVNSERVE is expecting "socket"
semantics (using one system file descriptor), whereas when it is using SSHD,
it is actually using "terminal client" semantics (with two system file
descriptors) ... the two semantics are not quite the same when it comes to
control flows or object lifetime management.
On the other hand, if the SSH were used to encapsulate a formal socket (or
even "pipe") in a VPN style tunnel, then there would be no issue.
This whole question is a fundamental design problem, not a band-aid
situation. It becomes really clear once you try to start some UML sequence
modeling of the objects being used on each end of the SVNCLIENT to SVNSERVE
session.
-Paul
Ps: but still raises the pragmatic issue of cost of implementing a
corner-case vs cost of support given the probability of occurrence.
> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: Sunday, October 25, 2009 4:36 AM
> To: Bob Denny
> Cc: Paul Charlton
> Subject: Re: off mailing list : Issue #2580 revisited: Windows unclean
> TCP close [SEVERE]
>
> On Sat, Oct 24, 2009 at 11:26:32PM -0700, Bob Denny wrote:
> > Paul and Stefan --
> >
> > Paul, I appreciate your comments and understand them. But both of you
> seem to be
> > (at least as I read it) looking at the situation from the bottom up
> (from the
> > TCP viewpoint). Look from the top down - from the SVN protocol:
> >
> > Let's take a simple example an svn client and an svnserve server
> connected by a
> > wet noodle. Over this noodle flows the svn protocol, as defined here
> >
> >
> http://svn.collab.net/repos/svn/trunk/subversion/libsvn_ra_svn/protocol
> >
> > How does the svnserve know when the svn client is finished with it
> (and that it
> > should exit)? There is noting in the svn protocol for this, so the
> server
> > depends on getting something like an EOF over the noodle.
> >
> > Replace the noodle with an SSH tunnel. svn and svnserve could care
> less that it
> > is SSH. The svn client closes its connection, the EOF flows through
> the tunnel,
> > pops out the other end, the svnserve sees it and knows it's time to
> exit.
> >
> > Now SSH _does_ have a closing protocol! It consists of:
> >
> > 1. The client end sends SSH2_MSG_CHANNEL_EOF ("I'm finished")
> > 2. The server end replies in kind with SSH2_MSG_CHANNEL_EOF (My
> svnserve exited")
> > 3. The server end follows with SSH2_MSG_CHANNEL_REQUEST (exit-status)
> > containing the exit status of the svnserve.
> > 4. The client end sends SSH2_MSG_CHANNEL_CLOSE
> > 5. The server end sends SSH2_MSG_CHANNEL_CLOSE
> >
> > FINALLY, at this point, each end is responsible for closing down the
> TCP
> > connection. Only now does the FIN/FIN exchange take place. Normally
> the client
> > end, the end that initiated the TCP connection, should close that
> connection by
> > sending the first FIN.
> >
> > Now let's look at what happens when the client svn kills its tunnel
> agent as
> > soon as it receives the last of the data it is expecting from the
> svnserve
> > server: None of the 5 steps above ever happen! The SSH layer client-
> server
> > protocol is instantly stopped, leaving the remote sshd wondering what
> the h*ll
> > happened, and its child svnserve waiting for something else to do.
> How long
> > should they wait? Should the sshd give up immediately, kill its child
> svnserve,
> > and exit? It could be argued that it should wait for another incoming
> connection
> > so they can do more work.
> >
> > The server end's TCP stack may be in the middle of ACKing some past
> packet and
> > that will be met at the client with a RST because there's no more
> socket, it's
> > owner was killed. But that's basically irrelevant. The real problem
> is that the
> > SSH protocol never got a chance to relay the fact that the client svn
> was done,
> > letting the svnserve gracefully exit, and the two tunnel agents never
> got a
> > chance to wind down their protocol either.
>
> That's a nice description of how it should work in theory.
> It would be nice and simple if closing the pipe to the ssh
> client was enough for things to settle down.
> In practice, not killing the tunnel agent didn't work out,
> at least when using svn+ssh and openssh connection pooling together.
> You end up with lots of ssh client processes idling about on the
> client machine (on UNIX).
> See http://subversion.tigris.org/issues/show_bug.cgi?id=2580#desc13
>
> Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2411166
Received on 2009-10-25 14:45:15 CET