Custom Query (2447 matches)

Currently, setting up Deluge to use a single port is very unreliable (that is, disabling random incoming port, and setting a port range of something like "52100 to 52100").

The issue is that re-starting the daemon will most often lead to the desired port being in use and a new random one chosen by the system.

The reason is that when a program frees up a port on Linux, it doesn't get immediately freed. It goes into a TIME_WAIT state, where it is available for fast re-binding in case an application changes its mind and wants it again. It's not fully killed off until a few seconds later.

To re-bind on the same port, Deluge will have to use libtorrent 1.6, which finally supports the TCP socket options to re-use the same port even if it's in the TIME_WAIT state, as well as a new option that refuses to bind if the desired port is in use (rather than choosing a random port).

It's described at ​http://code.google.com/p/libtorrent/issues/detail?id=305 but basically works as follows:

When migrated to lt 0.16, always use the session::listen_reuse_address flag to ensure it is allowed to re-use a TIME_WAIT port. if random_port == false && from_port == to_port, use the session::listen_no_system_port flag too to ensure that the system cannot change the desired port from what you wanted. If we could not bind the single port we wanted, kill the daemon and log a fatal error saying "port in use".

When a torrent is manually added, and the user types in a custom destination path, it makes no sense to tick the "Options - Move Completed" box in the torrent's options.

Example: Preferences - Default download path: ~/Downloads/incoming/, Move completed downloads to: ~/Downloads/complete/

Now the user adds a torrent, and the target path field of course defaults to ~/Downloads/incoming/, but the user instead types /storage/ and adds it like that.

The user has made the choice of where they want the file. Therefore, the "Options - Move Completed" box for that torrent should not be ticked, since the user obviously knows where they want the file to be placed.

To quote hydri (libtorrent author) regarding Deluge's port randomization: "<hydri> yeah, you should tell them not to do that.."

Try this: Start Deluge, connect to DHT, wait about half an hour, then disconnect again and re-start Deluge, letting it pick a new random port. Then go watch your router logs. About 2000 blocked connections per minute in my case. That's all the DHT peers trying to send you queries at your last known port.

Now, what happened? Well, when you meet other peers on torrents, you each exchange lists of all the DHT peers you know about. They add you to their list in this format: IP:PORT:FINGERPRINT. Then when THEY meet other peers, they keep passing this on, further and further. Suddenly, thousands or tens of thousands of peers know about your IP and port.

So, what happens when you change port all the time? Well, all those peers will be hammering your router at ports that are closed. At best, it means your DHT works much worse and that you're polluting the worldwide DHT tables. At worst, the DDoS-like "attack" might a crash a router that can't keep up with the thousands of blocked port messages per minute (it takes a bit of CPU and RAM to generate the text string for each blocked attempt in its internal logs; I've seen routers crash from this, mostly ones 8+ years old).

It also harms regular torrenting (TCP), because of peer discovery mechanisms. In that case, peers build lists of the IP and TCP port of all other peers, and then share these lists with each other. If your port has changed, you won't get connected to by those peers anymore. So, it's bad all around to have random ports on *every* launch.

The solution is so simple: Remove the "random port" checkbox, and change the dual incoming port "range" fields to a single port field instead. Next, on the first startup of the Deluge daemon, generate a port at random, and then stick to it. Allow the user to change the port if they want to, but using that single field to enter *one* port in. The process is as follows: "Install > first launch (rand() 49152-65535) == 53838 > every other launch = 53838". That way every user will still have a unique port, but it won't change on every launch, thus not harming DHT/getting your router DDoS'd. The port might still change occasionally due to being in use, but at least it will no longer happen on *every* launch, thus doing far less damage. Now, the OUTGOING ports on the other hand, should stay random (a port range); they have nothing to do with the torrent protocol. It's only the incoming port that needs to be static, for you to be connectable by other peers that know about you.

Finally: I spoke to Johnny, trying to figure out why this behavior was even in Deluge in the first place. Neither of us can see a reason. There is no benefit to having a random incoming port on every launch. Hiding traffic from the ISP by changing ports? No, your client still runs 24/7 for the most part and uses a single port all that time. If you really wanted to avoid any chance of ISPs detecting a lot of traffic on a single port, then the current feature is not gonna do it; the only way to combat traffic detection is to make a user-plugin that disables DHT, and then changes the libtorrent port every X minutes.

So, the current feature has no value and just harms the torrent protocol.

Lastly; libtorrent 16 has added a flag to "never let the OS pick a random port" (if port in use) for this exact reason, but it's not getting backported to lt15 so it cannot be used here. Here it is anyway for completion: ​http://upstream-tracker.org/changelogs/libtorrent-rasterbar/0.16.1/changelog.html "added session::listen_no_system_port flag to prevent libtorrent from ever binding the listen socket to port 0"