Opened 8 years ago

Closed 7 years ago

#4407 closed Enhancement (invalid)

Listening port should be closed when there's no activity

Reported by: felipec Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.42
Severity: Minor Keywords: patch-needed
Cc:

Description

I have paused all the torrents, yet, I notice my router has issues when I have transmission opened.

This command shows the problem.

% lsof -c transmission | grep TCP
transmiss 31382 felipec   13w  IPv4             549103       0t0      TCP *:51413 (LISTEN)
transmiss 31382 felipec   14u  IPv6             549105       0t0      TCP *:51413 (LISTEN)
transmiss 31382 felipec   21u  IPv4            2291844       0t0      TCP 192.168.1.33:51413->p5B36164A.dip0.t-ipconnect.de:64213 (ESTABLISHED)
transmiss 31382 felipec   33u  IPv4            2291881       0t0      TCP 192.168.1.33:51413->S01060026f3182830.rd.shawcable.net:49243 (ESTABLISHED)
transmiss 31382 felipec   34u  IPv4            2294819       0t0      TCP 192.168.1.33:51413->237.26.222.87.dynamic.jazztel.es:49221 (ESTABLISHED)
transmiss 31382 felipec   35u  IPv4            2293080       0t0      TCP 192.168.1.33:51413->c-65-96-201-184.hsd1.ma.comcast.net:54084 (ESTABLISHED)
transmiss 31382 felipec   36u  IPv4            2291891       0t0      TCP 192.168.1.33:51413->201-255-111-77.mrse.com.ar:4505 (ESTABLISHED)
transmiss 31382 felipec   37u  IPv4            2291892       0t0      TCP 192.168.1.33:51413->bas3-london14-1096788344.dsl.bell.ca:61442 (ESTABLISHED)
transmiss 31382 felipec   38u  IPv4            2290637       0t0      TCP 192.168.1.33:51413->175.141.210.155:50960 (ESTABLISHED)
transmiss 31382 felipec   40u  IPv4            2291743       0t0      TCP 192.168.1.33:51413->a89-153-210-214.cpe.netcabo.pt:49176 (ESTABLISHED)
transmiss 31382 felipec   42u  IPv4            2291871       0t0      TCP 192.168.1.33:51413->c-68-49-141-27.hsd1.md.comcast.net:57187 (ESTABLISHED)
transmiss 31382 felipec   43u  IPv4            2291751       0t0      TCP 192.168.1.33:51413->ip3e832aeb.speed.planet.nl:55489 (ESTABLISHED)

Transmission should close the listening port socket. Otherwise there will be unnecessary connections all the time.

Attachments (2)

tr-bug-active.txt (7.3 KB) - added by felipec 7 years ago.
Output of netstat while active
tr-bug-paused.txt (8.6 KB) - added by felipec 7 years ago.
Output of netstat while paused (3m)

Download all attachments as: .zip

Change History (27)

comment:1 Changed 8 years ago by jordan

  • Priority changed from High to Normal
  • Severity changed from Normal to Minor
  • Type changed from Bug to Enhancement

comment:2 Changed 7 years ago by roeme

  • Resolution set to wontfix
  • Status changed from new to closed

IMHO this can be deleted. LISTENING ports held open by transmission should by no means have any impact on a router. Unless transmission runs directly on it. But even in this case, the number of maximum peers (and so, connections), can be limited already.

comment:3 Changed 7 years ago by x190

roeme: Are you a member of the development team? If not, why are you closing other people's tickets?

comment:4 follow-up: Changed 7 years ago by x190

It's not that the listening port should be closed but the connections should be closed. I do not see this behavior using 2.21+ [2.42 +(13140) also tested with same results] and netstat (connections are closed).

Last edited 7 years ago by x190 (previous) (diff)

comment:5 Changed 7 years ago by x190

  • Resolution wontfix deleted
  • Status changed from closed to reopened

comment:6 Changed 7 years ago by x190

  • Resolution set to invalid
  • Status changed from reopened to closed

comment:7 Changed 7 years ago by cfpp2p

x190

thanks for testing with netstat and closing the ticket after verifying that this ticket really is invalid. seems like a good way to resolve tickets is by good trusted testing, patches, etc.. Thanks...

comment:8 in reply to: ↑ 4 ; follow-up: Changed 7 years ago by felipec

Replying to x190:

It's not that the listening port should be closed but the connections should be closed. I do not see this behavior using 2.21+ [2.42 +(13140) also tested with same results] and netstat (connections are closed).

This is wrong. Do you think this connection negotiation happens in some parallel dimension where it doesn't matter how many request per second are happening? Even if you deny all of them, and thus appear as closed in netstat, if you receive a billion requests per second, I can assure you there will be a degradation of performance somewhere.

I made it clear in the description:

I have paused all the torrents, yet, I notice my router has issues when I have transmission opened.

So. If it's not the ports being open, why is the router choking just by opening transmission, even if it's doing nothing? I think it's obvious what is the problem.

Please reopen.

comment:9 follow-up: Changed 7 years ago by felipec

Replying to roeme:

IMHO this can be deleted. LISTENING ports held open by transmission should by no means have any impact on a router. Unless transmission runs directly on it. But even in this case, the number of maximum peers (and so, connections), can be limited already.

Where do you think the TCP/IP socket requests pass through before reaching the system running transmission if not the router? Are they transmitted by magic?

Even if the router doesn't know what those bits mean, they are being transmitted before transmission denies the connection, either because the torrent is paused, or the maximum number of peers is exceeded. But routers actually do know what those bits means, and they also do some processing on those connection, as many have firewalls, and NAT, and so on. So those connection not only take network bandwidth, but also CPU and memory resources on the router, not to mention the PC, and other switches and routers involved in the route from one host to the other.

comment:10 in reply to: ↑ 8 ; follow-up: Changed 7 years ago by x190

Replying to felipec:

Replying to x190:

I made it clear in the description:

I have paused all the torrents, yet, I notice my router has issues when I have transmission opened.

So. If it's not the ports being open, why is the router choking just by opening transmission, even if it's doing nothing? I think it's obvious what is the problem.

DHT is still fully active as is tracker communication. Incoming connection requests might continue for a period of time after pausing torrents.

Please reopen.

Just want to make it very clear that if you follow the ticket history, it was roeme who in fact closed your ticket (apparently with the behind-the-scenes concurrence of livings124). I simply changed the resolution to what I felt was a more appropriate description. I do find it odd that you see ESTABLISHED connections with that command after pausing all torrents. Here is what I see after pausing all my torrents. All connections are closed. Setting up the LISTEN port is part of the way Transmission initiates a session.

lsof -c Transmission | grep TCP
Transmiss 192 sl   12u    IPv4 0x05ba6748       0t0     TCP *:53879 (LISTEN)

That said, you are more than welcome to re-open this ticket. You could perhaps help make your case stronger if you were able to document what other apps do in a similar situation.

Last edited 7 years ago by x190 (previous) (diff)

Changed 7 years ago by felipec

Output of netstat while active

Changed 7 years ago by felipec

Output of netstat while paused (3m)

comment:11 in reply to: ↑ 10 Changed 7 years ago by felipec

  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Version changed from 2.33 to 2.42

Replying to x190:

I do find it odd that you see ESTABLISHED connections with that command after pausing all torrents.

Yes, that's probably another bug.

Setting up the LISTEN port is part of the way Transmission initiates a session.

Which is wrong; that's the bug.

That said, you are more than welcome to re-open this ticket.

Done.

Here's the output of staring Transmission paused right away:

COMMAND     PID    USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
transmiss 22418 felipec   15u  IPv4 4769552      0t0  TCP *:51414 (LISTEN)
transmiss 22418 felipec   16u  IPv6 4769554      0t0  TCP *:51414 (LISTEN)
transmiss 22418 felipec   17u  IPv4 4769555      0t0  UDP *:51414 
transmiss 22418 felipec   20u  IPv4 4771547      0t0  TCP annwn:56902->stalker.h3q.com:http (SYN_SENT)
transmiss 22418 felipec   21u  IPv4 4770008      0t0  TCP annwn:60145->gudrun.archlinux.org:http (ESTABLISHED)
transmiss 22418 felipec   22u  IPv4 4769949      0t0  TCP annwn:42863->tracker.publicbt.com:http (SYN_SENT)
transmiss 22418 felipec   23u  IPv4 4769950      0t0  TCP annwn:52177->desync.com:http (ESTABLISHED)
transmiss 22418 felipec   24u  IPv4 4769951      0t0  TCP annwn:42536->TRACKER.novalayer.org:http (ESTABLISHED)
transmiss 22418 felipec   25u  IPv4 4769952      0t0  TCP annwn:60142->gudrun.archlinux.org:http (ESTABLISHED)

As you can see it's already doing something wrong by presumably contacting the trackers when there's no activity.

After a while it stabilizes, but for some reason a connection is always open, and it's weird that the IP address redirects to google.com:

COMMAND     PID    USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
transmiss 22418 felipec   14u  IPv4 4769551      0t0  UDP *:53991 
transmiss 22418 felipec   15u  IPv4 4769552      0t0  TCP *:51414 (LISTEN)
transmiss 22418 felipec   16u  IPv6 4769554      0t0  TCP *:51414 (LISTEN)
transmiss 22418 felipec   17u  IPv4 4769555      0t0  UDP *:51414 
transmiss 22418 felipec   21u  IPv4 4808105      0t0  TCP annwn:51405->lpp01m01-in-f141.1e100.net:http (ESTABLISHED)

The status is the same according to netstat:

tcp        0      0 annwn:51405                 lpp01m01-in-f141.1e100:http ESTABLISHED

Then, I enabled a single popular torrent, after which I get 84 connections according to netstat, and the limit number of peers per torrents I have configured is 10, then, after two minutes I pause, and after 3 minutes I check again, and now I have 98 connections. After several minutes now I have 138.

And yes, they are all from transmission because it's the only network application opened, the output of 'lsof -i' matches, and most of the connections are on port 51414 anyway, which is what transmission is binded to.

As I already explained, even if transmission was denying the connections immediately (which it doesn't seem to be doing), there's a lot of overhead already wasted just by having the port opened and constantly closing all the requests.

In fact, just as I predicted transmission is around 1% of CPU even while doing nothing, which is enough to put at the top of top in my system (because I'm not doing much).

Why do you think pausing the torrents would make a difference to the people on the other side of the network? When they search for peers they would still find you, so they will try a connection.

You could perhaps help make your case stronger if you were able to document what other apps do in a similar situation.

Why do you need that? That's sockets 101; if you are not going to use it, close it. What's the point of listening to the socket if you are going to deny all the connections. The only thing you achieve is waste resources, and in my case, degrade the network performance.

BTW, this is on version 2.42 (13013).

comment:12 in reply to: ↑ 9 ; follow-up: Changed 7 years ago by roeme

Replying to felipec:

Replying to roeme:

IMHO this can be deleted. LISTENING ports held open by transmission should by no means have any impact on a router. Unless transmission runs directly on it. But even in this case, the number of maximum peers (and so, connections), can be limited already.

Where do you think the TCP/IP socket requests pass through before reaching the system running transmission if not the router? Are they transmitted by magic?

Even if the router doesn't know what those bits mean, they are being transmitted before transmission denies the connection, either because the torrent is paused, or the maximum number of peers is exceeded. But routers actually do know what those bits means, and they also do some processing on those connection, as many have firewalls, and NAT, and so on. So those connection not only take network bandwidth, but also CPU and memory resources on the router, not to mention the PC, and other switches and routers involved in the route from one host to the other.

Those bits you are referring to are transmitted regardless of wether a port is held open by transmission or not. The solution lies in x190's answer:

DHT is still fully active as is tracker communication. Incoming connection requests might continue for a period of time after pausing torrents.

This will cause traffic and connections. Which in turn, for some reason or another, your router isn't able to handle. I'm just wondering, if your router already has problems with an idle transmission doing DHT, how are you not having problems when actually downloading?'' Can't get my head around that. Furthermore, to resolve the real problem (as it's presented now), one would have to implement a central structure controlling port "allocations". As far as I can tell, this would be quite a big chance - only to work around inadequate hardware.

This is why I agree that invalid might be the better resolution for this ticket.

Some years ago, I did experience the same problems when torrenting. The solution was to replace my outdated router; the old one simply had not enough RAM to keep a decent sized state table. It was either that, or limiting the bittorrent client to only a few peers and torrents.

Before further diving into it, please test with the most recent version of transmission, as x190 did.

Replying to x190:

Just want to make it very clear that if you follow the ticket history, it was roeme who in fact closed your ticket (apparently with the behind-the-scenes concurrence of livings124).

x190, while it's perfectly okay to set things right and state that I have closed the ticket originally, please refrain from snide remarks and accusations. It only stirs up thing unnecessarily and creates a hostile environment. Even though we disagree(d) on some topics, we can do so on a mature level. In a way that helps the matter at hand.

comment:13 in reply to: ↑ 12 ; follow-up: Changed 7 years ago by felipec

Replying to roeme:

Replying to felipec:

Even if the router doesn't know what those bits mean, they are being transmitted before transmission denies the connection, either because the torrent is paused, or the maximum number of peers is exceeded. But routers actually do know what those bits means, and they also do some processing on those connection, as many have firewalls, and NAT, and so on. So those connection not only take network bandwidth, but also CPU and memory resources on the router, not to mention the PC, and other switches and routers involved in the route from one host to the other.

Those bits you are referring to are transmitted regardless of wether a port is held open by transmission or not.

Yes, which is already an issue. Shouldn't there be a way for transmission to tell the tracker that it shouldn't be used any more? And of course, if transmission is using nat-pmp it could remove the port from the forwarding, and thus the router will drop those bits, and they will never reach the transmission system.

The solution lies in x190's answer:

DHT is still fully active as is tracker communication. Incoming connection requests might continue for a period of time after pausing torrents.

This will cause traffic and connections.

Yes, but for how long? 30 minutes?

And again, closing the socket can only help.

Which in turn, for some reason or another, your router isn't able to handle. I'm just wondering, if your router already has problems with an idle transmission doing DHT, how are you not having problems when actually downloading?'' Can't get my head around that.

I have problems while downloading, that's why I pause.

Furthermore, to resolve the real problem (as it's presented now), one would have to implement a central structure controlling port "allocations". As far as I can tell, this would be quite a big chance - only to work around inadequate hardware.

Just close the damn socket. What's so difficult about that?

Before further diving into it, please test with the most recent version of transmission, as x190 did.

I am not going to do that. You answer first: Why not close the socket?

comment:14 in reply to: ↑ 13 Changed 7 years ago by roeme

felipec, jfyi: because of the moderation, my answer was chronologically out of order....

Replying to felipec:

Which in turn, for some reason or another, your router isn't able to handle. I'm just wondering, if your router already has problems with an idle transmission doing DHT, how are you not having problems when actually downloading?'' Can't get my head around that.

I have problems while downloading, that's why I pause.

Now we're getting somewhere! I strongly suggest getting to the root of this problem and solving it. By pausing and/or disabling transmission, one does only work around the problem instead of solving it. It's like sticking a patch on a cracked windshield instead of replacing the windshield.

And frankly, why should transmission be changed fundamentally because some inadequate hardware can't handle the load of the bittorrent protocol doing multiple torrents? Also, there might be some other machines on your network causing excessive connections.

Furthermore, to resolve the real problem (as it's presented now), one would have to implement a central structure controlling port "allocations". As far as I can tell, this would be quite a big chance - only to work around inadequate hardware.

Just close the damn socket. What's so difficult about that?

(Hey now. Just damn behave. What's so difficult about that?) Now. If it's so easy, why don't you provide a patch? And anyway, I explained it why it might be so difficult.

Before further diving into it, please test with the most recent version of transmission, as x190 did.

I am not going to do that. You answer first: Why not close the socket?

Wait. Did I get this right? You have a problem, You want it solved, but you won't help? Also, note that my answer was chronologically out order. I did see that you already had it tested with 2.42, so this is no longer of importance.

Setting up the LISTEN port is part of the way Transmission initiates a session.

Which is wrong; that's the bug.

You seem to know better than the devs...?

In conclusion, I still regard this ticket as invalid; more than before. Reasons are all stated in the above/below comments. Fix your setup and/or seek help in the forums. If none of the devs comments here, I will close this ticket soon. Try to reach out to them if you disagree.

comment:15 follow-up: Changed 7 years ago by x190

This seems like a defective/poor quality router issue, so unless devs wish to change the LISTEN port behavior, IMO this ticket can be marked as "Invalid".

comment:16 follow-up: Changed 7 years ago by jordan

  • Resolution set to invalid
  • Status changed from reopened to closed

comment:17 in reply to: ↑ 15 Changed 7 years ago by felipec

Replying to x190:

This seems like a defective/poor quality router issue, so unless devs wish to change the LISTEN port behavior, IMO this ticket can be marked as "Invalid".

So are you saying transmission only works properly with certain routers?

I guess it's time to look for another bittorrent client that is not full of itself.

Now, can you answer this question? "Can transmission close the socket" (Yes, or No) It's a simple question.

comment:18 in reply to: ↑ 16 ; follow-up: Changed 7 years ago by felipec

  • Resolution invalid deleted
  • Status changed from closed to reopened

Replying to jordan:

Answer the question, don't hide behind censorship curtains: Can transmission close the socket? Yes or No.

comment:19 Changed 7 years ago by livings124

  • Resolution set to invalid
  • Status changed from reopened to closed

Transmission can't be expected to work with defective/poor quality hardware. This is a hardware issue, not a Transmission issue.

comment:20 in reply to: ↑ 18 Changed 7 years ago by jordan

Replying to felipec:

Replying to jordan:

Answer the question, don't hide behind censorship curtains: Can transmission close the socket? Yes or No.

What the fuck? You asked the question after I closed the ticket, and then claimed I was censoring the question by closing the ticket.

In the first place, you've got your chronology backwards. In the second place... censorship? really?

Plonk.

comment:23 Changed 7 years ago by Dr.Pat

  • Resolution invalid deleted
  • Status changed from closed to reopened

Hi, sorry if i'm bad, but I also think that this really is an issue. Maybe we may just focus on solving the issue, instead of insulting each other.

I use various clients, all with DHT disabled, and when they're not downloading, they don't appear on the router connections list. When i use Transmission (DHT disabled as well), in no more than 60 seconds 100-200 connections appear. No performance problems, at least for me, but it's very difficult to analyze traffic when someone is using transmission on the LAN. Other clients, at least to me, show this many connections with no current downloads only when DHT is enabled.

I simply think that this isn't the intended behaviour for the end-user, or that the DHT check doesn't work as intended. If one isn't downloading anything, and DHT is disabled, then I think that nothing should appear anywhere. uTorrent and Synology Download Station don't have this "issue".

Just see this screenshot, 3 clients opened on the LAN, but only Transmission appear: http://dl.dropbox.com/u/9861508/transmission-connections.png

Thanks!

comment:24 Changed 7 years ago by x190

Dr. Pat: Are you using version 2.42 (13013) or later? What form of Transmission are you using and on what OS? What do you mean by "they're not downloading" or "no current downloads" and how many trackers are involved? Also, what do you mean by "connections", i.e., are they "ESTABLISHED" or something else?

comment:25 Changed 7 years ago by Dr.Pat

I'm using Transmission 2.42 on a Synology NAS DS411+II (x86, Linux based, 2.6.32 kernel), installed through a package; i can configure T both from the the web interface and with the json configuration file. I don't have any other issue with T (e.g. the settings that i change take effect).

By "not downloading" or "no current downloads" i mean that I don't have any torrent; the list is empty. I think that the same should apply when some torrents exists and all are paused.

I don't know if they connections are "ESTABILISHED", but i'll check as soon as possible. I just check visually from the router (see previous screenshot) and also see that the LAN and WAN activity leds go crazy when i start Transmission with empty download list and DHT disabled. Intended behaviour, for me, is that if DHT is disabled and Transmission is just sitting idle (as a daemon) with no torrents, it should also not accept connections and keep minimal footprint.

My current workaround is this: disable DHT, then change port; this way, I think, others don't know i'm online and don't try to contact me. That's not very robust imho.

comment:26 Changed 7 years ago by jordan

  • Keywords patch-needed added
  • Resolution set to invalid
  • Status changed from reopened to closed

IMO this is a minor ticket at best and is not worth the noise level in this ticket or the insults being thrown at the developers in this ticket, so I'm not going to mess with it.

If someone wants to submit a patch that's been tested & works, please attach the patch and then reopen the ticket.

Note: See TracTickets for help on using tickets.