TCP connections left open

[sethg]

From my posts in the "Troubleshooting" forum, it appears there are one or more bugs with TCP port usage. Here's what I've observered.

1) TCP port connections for some clients that are no longer in the peer list remain open.

2) Some peers have three TCP connections open. I thought there should be at most two connections for a peer and one for a seeder, though I don't know the details of the BitTorrent protocol.

3) TCP connections for peers remain open after a torrent is stopped.

4) Some TCP ports for peers remain open after uTorrent exits.

5) After uTorrent exits, former clients with TCP connections still open continue to send information over those connections. These are blocked by my firewall, but the connections should have been closed.

[vurlix]

We'll definately look into this.

[vurlix]

By connections staying open, do you mean connections in the TIMED_WAIT state?

[wldcat2]

If I recall correctly from when this happened yesterday, then no. It was not timed mode, it was actually still connected. Only way for me to close them was to reboot. Unfortunately that was a big enough issue for me to go back to ABC. But since 1.1.5 is out now I'll give that one a try

[wldcat2]

Ok, I just tried it again and it seems to be working normally. A couple of seconds after closing uTorrent there were 3 connections open (in the Timed Wait state) but then a few seconds after that they were all close. So I don't know if there was a change from 1.1.4 that helped this or not but it seems to work normally now for me anyway.

[aye29]

I'm using 1.1.5 and after I close utorrent Outpost Firewall is still reporting that it is blocking incoming attempts to connect to my Bittorrent port. I had the same problem with 1.1.4.

Also what does timed wait state mean and how would I check that?

[Firon]

timed_wait is one of the connection statuses that netstat reports, though I don't personally know what it means.

The incoming connections are probably other peers who have you in their peer list and are still trying to connect to you, because they couldn't before, or something.

[sethg]

The connections were established, not time_wait. Many of them even came back after I rebooted, which was initially surprising until I realized that my machine would accept an incoming connection request on the uTorrent port and respond whether or not the application was running. There would be a TCP connection at the port requested by the remote client, but no running process would be attached to that socket. I would regard this as a minor security risk, it's more of an indication that things aren't working quite right.

Just for fun, I set uTorrent to not start on reboot, blocked the uTorrent port on my firewall and rebooted the machine. It's been over a day since I've run uTorrent and my firewall is still showing hits on the uTorrent port. My machine was even turned off for part of this time. I recognize some of the machines attempting to connect as previous peers. This leaves me wondering whether this is due to:

1) a flaw in those clients (failure to delete a dead peer's IP),

2) a flaw in uTorrent 1.1.4 that didn't close connections with peers upon exit,

3) a flaw in uTorrent 1.1.4 that didn't inform the tracker that we were going bye-bye or

4) a flaw in the tracker that didn't act on the bye-bye message.

I'll report back what I find with 1.1.5.

[vurlix]

This doesn't seem to be an issue with µTorrent. If peers are still hitting your µTorrent port after being off for a day... The problem lies in the peers and/or tracker.

[sethg]

This doesn't seem to be an issue with µTorrent. If peers are still hitting your µTorrent port after being off for a day... The problem lies in the peers and/or tracker.

Agreed. The only questions pertaining to uTorrent are if it properly informs the tracker that it is no longer part of the swarm (assuming the BT protocol supports that functionality) and that when stopping, deleting or removing a torrent, or shutting down uTorrent, it closes all open TCP connections with clients and trackers. If those same clients/trackers come back and reconnect after you tell them not to, that's their fault.

I just want to make sure that we properly inform the tracker of our departure and close all open connections. Does the code attempt to do that?

[vurlix]

Yes, it does.

[sethg]

Here's what I've observed with 1.1.5. I used "netstat -n 5" in a DOS Window as a tool to view the connections every five seconds and enabled logging in uTorrent. The condition was two torrents that completed downloading, seeded to 150% and went into non-prioritized seeding mode at reduced upload rate. When I hit stop on each of the two torrents, the peer list immediately disappeared from each. However, the netstat display showed that none of the connections closed immediately. Instead, the connections slowly dropped off one at a time. After several minutes, the number of connections reduced from about twenty to about ten. The number of connections keeps going down with time.

As a second test, I restarted one of the torrents, waited for connections to open and upload rates to build, then stopped the torrent. The first thing I noticed is that the log shows incoming connections but doesn't show connection closures or outgoing connection requests. Edit: Outgoing connection requests do appear. Sorry. The second thing I noticed is that the log shows that individual peers do periodically reconnect and netstat shows them disconnecting again after a while. The overall picture is that the number of connections gradually decreases, with individual peers occassionally reconnecting and dropping off again. Unfortunately, I was unable to copy the log window contents or save it, but you get the idea.

My guess from this behavior is that uTorrent is communicating our departure to the tracker, but it does not appear to close any of the open peer connections. Instead, it appears to wait for the peers to get tired of getting no data from us and disconnect on their own. They periodically reconnect, see no data from us and disconnect. This continues until they either take us off their IP lists on thier own or contact the tracker and see our IP is no longer listed. Perhaps I am missing what is really going on by only looking at a connection snapshot every five seconds and a log file that doesn't show disconnect events.

I don't know if there is any way in the BT protocol to tell a peer that we are leaving besides just closing the connection. I ask because we don't want the peer to keep reconnecting unnecessarily. Maybe this is simply not possible. At the very least, perhaps we could close all open connections when we stop a torrent to expedite the process of getting off the peer's IP lists.

[ludde]

uTorrent already closes all connections when you click the close button. What you see is probably Windows trying to end the TCP connections.

[sethg]

uTorrent already closes all connections when you click the close button. What you see is probably Windows trying to end the TCP connections.

The connections seem to disappear at the rate of a few per minute. It only takes a few milliseconds to close a TCP connection so something is not right. Some of these connections are peers that you are actively downloading or uploading to, so there is not an issue with them not reading their buffers for extended periods. None of the connections seem to close immediately when you hit stop. It looks more like the connections are closing due to timeouts rather than being actively terminated. I don't know the Windows internals, but maybe there is something wrong with the particular MS method that you use to close connections?

[ludde]

It takes like 240 seconds to close a TCP connection because of the TIME_WAIT state.

[sethg]

It takes like 240 seconds to close a TCP connection because of the TIME_WAIT state.

As I said, I don't know the Windows internals. You can close a TCP connection without going into TIME_WAIT and timing out. You can see this by watching the operation of any MTA in Linux. An SMTP transaction starts, you check their IP against a DNSBL and if their IP is blacklisted, within a millisecond or so the TCP connection is gone. What the MTA does is send the connection closing message, then closes the connection. The client at the other end may not realize the connection has closed until they read their input buffer, but that's life. The RFC's say you're supposed to wait for the client to acknowledge, but when you're talking to spammers, why bother being polite?

Once the socket is closed, it consumes no local resources. Since the most popular MTA, Sendmail, has throughput that is socket/process limited, it would be completely unusable if it had to wait four minutes to close every unwanted connection. That would be a built-in self-DoS mechanism, and I can assure you that no commercial MTA product hangs on to an unwanted TCP connection for more than a few milliseconds. With the need to maintain a few thousand open connections at a time, this would be suicide.

I can't tell you what Windows methods are available, but you don't have to let the other party time out to terminate a connection.

[Niceguy]

hmm... yes I noticed this on 1.14, after closing utorrent on 1.14, incoming connections were blocked by my firewall for a short while, although the utorrent process where no longer running, indicating that the listening socket hadn't been closed.

the default shutdown state of a socket iirc is SO_DONTLINGER, which will close the socket in the background at it's own leisure after a call to closesocket. likely this is what is causing the delay between the application and the socket shutdown. I know there was some way to set the socket option with a zero time out value to close the socket immediately, but I can't remember what it was, and I'm too lazy to look it up right now

another way would be to issue a shutdown() call on each socket, and then await FD_CLOSE on them, before calling closesocket, this *should* ensure that there would be no pending data/signals on the sockets, and therefore closesocket would not linger.

bear in mind that it was a long time ago that I did any socket programming, so I may be talking out of my arse here (as usual ).