#2121: Rework Deluge towards static incoming port
-----------------------------+----------------------------------------------
Reporter: bmnot | Owner:
Type: feature-request | Status: new
Priority: critical | Milestone: 1.4.0
Component: core | Version: other (please specify)
Keywords: |
-----------------------------+----------------------------------------------
Changes (by bmnot):
* priority: major => critical
Comment:
This is actually way more important than I made it out to be.
DHT works by all peers you encounter (whether that's via torrents or DHT
or any other method) building lists of each other's IPs and ports.
These lists get populated as you encounter peers, and then they get shared
around to other peers asking for DHT peer lists, for bootstrapping
purposes.
So, what happens when you have a bad torrent client that uses a dynamic
incoming port? Well, you break DHT quite badly.
What happens is that you will pollute the peer tables of *all* other peers
you ever met, with false port numbers that you are no longer listening to.
Meanwhile, those peers will be trying to connect to your now-invalid port,
as well as sharing this information with other peers.
The end result is that you keep polluting DHT with invalid IP:port pairs,
and peers in turn will be hammering your router on invalid ports, causing
it a great deal of load (particularly to generate all the failure/blocked
log messages).
So, it's best to (as a user) set Deluge to "Use Random Port: No", and set
the Incoming Port Range From/To values to the same port, to enforce a
single port and ensure clean DHT behavior.
There's only one issue with this workaround, and that's the fact that re-
binding the same port will fail if you start the Daemon immediately after
you last shut it down (i.e. with a daemon restart script). You'll have to
stop the daemon, wait like 10 seconds, and start it again to ensure that
the port will be properly available, or you'll once again end up in
"random port" territory.
Sadly a proper fix to this behavior and a move to a single-port model
would kind of require libtorrent 0.16, which finally includes support for
fast re-binding and forcing a certain requested port.
There is *one* workaround that could be done even with libtorrent 0.15,
and it's as follows: First, instantiate libtorrent using the requested
single port you want (such as 54321), next, query libtorrent to see what
port it actually assigned to. If it wasn't 54321, do NOT proceed, do NOT
start DHT, just immediately close the daemon and log a "port was in use"
error message. Alternatively, a re-try could possibly be implemented too,
such as "port not the same as we requested? un-load libtorrent, load it
again, wait 5 seconds, try to bind to that port one last time and see if
we got it this time".
--
Ticket URL: <http://dev.deluge-torrent.org/ticket/2121#comment:1>
Deluge <http://deluge-torrent.org/>
Deluge project
--
You received this message because you are subscribed to the Google Groups
"Deluge Dev" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/deluge-dev?hl=en.
