Opened 14 years ago

Closed 14 years ago

Last modified 13 years ago

#767 closed Enhancement (worksforme)

choose port from a range rather than rely on a single default port

Reported by: anders Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 1.06
Severity: Normal Keywords:
Cc:

Description

If multiple users on the same system run multiple instances of transmission, they're likely to mess up with each others transmission listening ports. The same applies if transmission is used in an automatic environment, where e.g. multiple instances of transmissioncli may be in use by the same (unix) user. Choosing a random port from the command line isn't that easy and may still lead to race conditions, so I suggest that transmission helps to solve this problem.

Suggestion: if the port option is set not to a single port but to a list (e.g. "49152-65535"), make transmission try those ports until either the list's end has been reached or a usable port has been found.

Change History (3)

comment:1 follow-up: Changed 14 years ago by charles

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

I'm not totally opposed to this, but I'm not convinced that the added complexity is worthwhile: I run multiple copies of Transmission on my home machine under the same user account (one for actual use, one for development & testing) and get along fine by setting a different port for each instance. I think a port list is perhaps overkill for a fringe case like this.

Marking as closed, but, as I said, I'm not /totally/ opposed to this... if there's a great clamor for port lists in the forums or irc, someone can re-open and explain why this is a necessary feature.

comment:2 in reply to: ↑ 1 Changed 14 years ago by anders

Replying to charles:

I'm not totally opposed to this, but I'm not convinced that the added complexity is worthwhile: I run multiple copies of Transmission on my home machine under the same user account (one for actual use, one for development & testing) and get along fine by setting a different port for each instance. I think a port list is perhaps overkill for a fringe case like this.

Well, I'm running transmission-cli on a few hundred linux servers; transmission-cli is (along with the rather buggy ctorrent-dnh) about the only bittorrent client which allows me to execute a script upon completion of the supplied torrent. I'm using transmission to distribute software images (tarballs) among those servers using those images; once a server receives the image, it should run a few shell scripts to install that image.

transmission-daemon doesn't offer that feature ("--finish"), so I can't switch that easily to transmission-daemon and would have to work around that by creating a seperate process which checks for completed downloads - something rather stupid, as the needed function is already present in transmissioncli.

If the default port is currently in use (by some other process on the same box, e.g. an FTP session), transmission says about every second that the port is currently in use. The download starts, but this node won't re-distribute the received image.

I don't want to kill the process using "my" port (as the receiving process is automated and doesn't know when it's okay to kill some other process), so I'd have to take a guess on which port is not in use when transmission tries to bind() it. One "solution" for this problem is

# transmissioncli -p $((RANDOM+32000))

... which asks the shell to return some random number from 1-32768, add 32000 to it and use that number as the port. However, this random choosen port may also be in use. Before I do add some complexity to a shell script, I'd rather like transmission to implement a rather simple range scan. After all, e.g. netcat includes a different approach: bind to a random port when not being called with a specific port:

$ nc -v -l listening on [any] 35377 ...

$ nc -v -l listening on [any] 54123 ...

$ nc -v -l listening on [any] 53875 ...

Marking as closed, but, as I said, I'm not /totally/ opposed to this... if there's a great clamor for port lists in the forums or irc, someone can re-open and explain why this is a necessary feature.

Well, I thought of merely allowing input like "49152-65000" in the port field and transmission trying to allocate "the next" port from that range in case the just tried port is in use.

The necessary code is rather simple - here written in pseudocode:

$rangelo=$defaultport; $rangehi=$defaultport;

if ($defaultport =~ /(\d)+-(\d)+$/) {

$rangelo=$1; $rangehi=$2;

}

$currentport=(); foreach $port ($rangelo..$rangehi) {

if bind($port)==0 {

$currentport=$port;

}

}

if (!($currentport))

warn ("unable to open port $defaultport.");

comment:3 Changed 13 years ago by add

by end users who would like to contribute and start to use docs to learn cool stuff about their apps in the first place. Both annotations and contributions will only clutter the interface by default as a design pattern rather than trying to put it all together. That way you can never create offline or print docs of high quality without again having the devs or current admins maintain the comments and annotations. Hopefully a small Wiki quality team will evolve (i am against ops or admins) to review and summarize the contributions. I hope this gives us more users as contributors than having the docs focused on the devs. Cheers, duns china tour Apparel shoes bags Kitchen Food and Wine Furniture) Flowers and Gifts Wall Art Computer Components I still prefer a wiki like approach since the php (or mysql) docs are very cluttered when you have to take their comments in account. On the other hand they are professionally maintained imho, since they are *much* better than KDE documentation. KDE is by far larger and has so many different apps, which need screenshots and end user not dev/api docs

Note: See TracTickets for help on using tickets.