transmission
transmission copied to clipboard
transmission
feat: don't default to port 51413 on new installs; assign random port instead
What is the issue?
Right now, every new installation uses port 51413 for some reason.
This adds a level of predictability to Transmission that we should consider removing by simply randomizing the port for new installs instead of using the same port for every install. Which ports should we randomly pick from? The so-called ephemeral ports below:
The Internet Assigned Numbers Authority (IANA) and RFC 6335 suggests the range 49152–65535 (215 + 214 to 216 − 1) for dynamic or private ports.[3][4]
Hopefully, this is already the port range Transmission selects from when checking "pick a random port every time Transmission is started"
By randomizing the port for new installs, we make it less likely for Transmission to be blocked in some way and for new users to have more chances of success when connecting to swarms after installing Transmission, since many users are unlikely to change the port on their own unless they are familiar with optimizing their torrent client.
Which application of Transmission?
Qt app on Windows
Which version of Transmission?
Transmission 4.0.0-dev (3ae8107)
I'm not sure how I feel about this.
Randomizing inarguably does make life harder for anyone trying to block Transmission and/or trying to use it as an attack vector, but it also could make life harder for people trying to follow a user guide on port forwarding or set up Transmission in a predictable way from an image or package. So there are tradeoffs and (IMO) not one clear Right Thing.
@Pentaphon what is the default behavior in the other clients, e.g. uTorrent, qBitTorrent, Deluge, rTorrent, et al?
I'm not saying to check the "randomize port on each start" by default. I am saying every new install of Transmission should assign the user a random port. For example, if 10 users install Transmission, then they are all assigned a different port rather than having the same port, and this port remains the same for them (just like it currently does) until they decide to change it. Every new install should assign you a random port from the ephemeral port range. If a user uninstalls Tranmission, they will get a different port number the next time they install it. This is exactly what qBittorent does since 4.0.0 ( or sooner? Not sure.) to do things differently from uTorrent which used to give every user the 6881 port by default upon install which as you can imagine led to users having connection issues if 6881 were being blocked by their ISP.
This would not affect users who want to port forward because the random port number assigned to their new install would still be static. There would just be a different port number upon each unique install rather than the same 51413 port.
Libtorrent based clients let the OS decide a random port on first start, then keep that port across future sessions.
Discussed in a note at the bottom here
Asking the user to open up the settings GUI to grab the random port number initially generated on first install shouldn't be a big step for setting up a port forward, in my opinion.
I'd see a problem if routers had hardcoded Transmissions default port in their port forwarding/mapping sections, but I don't believe this is the case.
+1 from me on the suggestion.
On a side note, I think there should be a mention in the docs about the caveat of ticking "randomize port on each start", as it will take time for your new port to propagate across the swarm and potentially lead to slower downloads on start up.
More discussions over at QBitTorrent here
Libtorrent based clients let the OS decide a random port on first start, then keep that port across future sessions.
Ah so that's where it comes from. Thank you for that info. It is certainly a slight advantage that all the libtorrent-based clients have over Transmission that can easily be tweaked and make new installs less likely to be blocked when connecting to swarms.
@ckerr perhaps this can be tagged as a "good first issue" and a "PR welcome" for anybody out there who wants a smaller task than something more difficult (like the hole punching BEP) to tackle on their own? Unless of course, one of the regular contributors can get this done for an upcoming 4.0.x patch version.
On a side note, I think there should be a mention in the docs about the caveat of ticking "randomize port on each start", as it will take time for your new port to propagate across the swarm and potentially lead to slower downloads on start up.
This is a really good point and it's probably going to get lost in this thread. @Coding4Coffee could you open a standalone ticket for it so that it cant be tracked? Thanks!
@ckerr perhaps this can be tagged as a "good first issue" and a "PR welcome" for anybody out there who wants a smaller task than something more difficult (like the hole punching BEP) to tackle on their own? Unless of course, one of the regular contributors can get this done for an upcoming 4.0.x patch version.
This would be a new feature, not a bugfix, so it's not eligible for 4.0.x
On a side note, I think there should be a mention in the docs about the caveat of ticking "randomize port on each start", as it will take time for your new port to propagate across the swarm and potentially lead to slower downloads on start up.
This is a really good point and it's probably going to get lost in this thread. @Coding4Coffee could you open a standalone ticket for it so that it cant be tracked? Thanks!
👍🏼 Done: #4942
This would be a new feature, not a bugfix, so it's not eligible for
4.0.x
I suppose you're right. It seemed very minor, like hardly a feature but more of a correction, but I guess we are being strict with the whole semver thing.