[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

svn+ssh prevents other connections, scp does not

From: Russ Lewis <webmaster_at_villagersonline.com>
Date: 2006-01-06 19:26:24 CET

NOTE: Don't think that this is *only* an svn+ssh problem, since this
started happening recently and I haven't recently changed my version of
svn. But, since this happens with svn+ssh but not with other
heavy-traffic ssh connections (such as scp), I am hoping you guys might
be able to tell me what svn+ssh does *different* than other connections.

I have a DSL connection at home. I have 2 computers there, both running
Linux. One (my desktop system) has a large (several GB) svn
repository. The other is a web server and DNS server. I have noticed,
over the last few weeks, that I have been losing the ability to connect
into these machines from time to time. More specifically, I cannot make
any other *new* TCP connections during certain windows (existing TCP
connections work fine).

I have finally narrowed it down, I think: I fail to make new TCP
connections (to either machine at home) when I am doing long-running svn
updates over svn+ssh. To track this, I first opened up an ssh shell to
my desktop at home. I then started up an svn update (from an external
machine into the repository on my desktop at home). That works fine.
Then I start a 2nd update (from a different external machine into the
same repository). That hangs. I do "netstat" on the desktop machine at
home and I see that the new connection is hung in the SYN_SENT state.
During this window of time, new connections into the web server (the
other machine at home) also get hung. But if I Ctrl-C the first svn
update, then everything wakes up and works fine.

However, if I replace the first "svn update" with a long-running scp
command, then we don't get this problem.

I don't know, but I assume that the SYN_SENT state means that Linux
heard the incoming SYN and sent its response, but has not heard anything
more. My best guess is that this means that the outgoing response
packet is getting dropped. It seems like these packets are getting
dropped while the svn+ssh is connected, and not otherwise.

I'm guessing that this is at least partly a problem with either my DSL
router or my ISP (the outgoing connection responses should not be
dropped), however, I wonder why svn+ssh causes this problem while scp
does not. Does svn+ssh set unusual TOS parameters, perhaps? Or
something else?

    Russ Lewis
    svn fan

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 6 19:29:39 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.