Localports exclusion

[realcool]

If there is a service/app. that uses a specific localport (or range of ports), when it try to start is possible that it cannot do it because the port is being used by Utorrent.

The only solution is wait to utorrent releases the localports or stop utorrent, or always initiate the service/app before utorrent (without concerning how many resources the service consumes and if you dont know that you really will need to use it in current session).

If utorrent excludes localports to not use them, could be the solution to be able to run services or apps (like e-mule or java appserver) when utorrent already is initiated without any problem.

[Firon]

What?

[Switeck]

What are local ports?

[realcool]

The localports are ports used by any client of local computer (my computer) to connect to any others over ethernet. In this case they are ports used by utorrent for incoming and outgoing connections.

The idea is to tell to utorrent by some way that does not use certain ports for outgoing connections. No problem for incoming connections, I can change the port in Network options.

[Ultima]

bt.no_connect_to_services + bt.no_connect_to_services_list

[realcool]

Yeah, but this option tells µTorrent not to connect to peers using ports as "their" listening ports. This ports are of them not mine.

In this case is to tell µTorrent not to connect to peers using "my" ports as "my" outgoing ports (in computer where µTorrent are running). In this way I could use this ports as "my" listening ports for my services even utorrent was already launched because µTorrent never will use them.

[Ultima]

Um. Huh? If other peers are attempting to connect to µTorrent via ports *other* than the listening port, then it's none of µTorrent's business, and µTorrent *doesn't* connect to them. I'm not even sure what you're asking for anymore. Even *if* it's only "their" listening port, as long as the port is specified in bt.no_connect_to_services_list, µTorrent will NEVER bother connecting to the port.

[realcool]

When utorrent is connected to another peer, it does it from a local port in its computer towards the listening port in the computer of other peer in outgoing connections. Only incoming connections uses utorrent's listening port as local port to make this connection.

Windows

----------- (a)

| (1) <----------------------------- (2) PEER 1 (They make connection with utorrent)

UTORRENT |

| (3) -----------------------------> (4) PEER 2 (utorrent makes connection with them)

----------- (

(1) Local listening port (Utorrent's computer - example: port 6881)

(2) Remote outgoing port (Peer1's computer - port dinamicaly assigned by Peer1's operating system)

(3) Local outgoing port (Utorrent's computer - port dinamicaly assigned by win os)

(4) Remote listening port (Peer2's computer)

(a) Incoming connection

( Outgoing connection

The idea is not no connect to some port of peer (that utorrent already can do), the idea is utorrent does not connect from certain ports in its computer (of utorrent) to other peers, ports which are assigned dynamically by Windows.

Like option net.outgoing_ip makes µTorrent use a specific LAN adapter for all outgoing connections, an option like "net.outgoing_ports_filter + net.outgoing_port_filter_list" could tells µTorrent not use specific ports for all outgoing communication.

[Switeck]

Bind µTorrent to an OUTGOING port in advanced settings.

Also, µTorrent should only be using its incoming port for BitTorrent traffic.

There is some other incoming ports used for tracker communication as well, but I don't know enough to tell you what to do with that.

If you're seeing LOTS of incoming traffic on ports 1026-1029 like I am right now, it's probably just the latest Windows messager worm/virus making its rounds and hammering your ip. That's got nothing to do with µTorrent as far as I know.

[Ultima]

What I don't understand is why anyone would want to use the ephemeral ports as a static listening port for *anything*, but oh well.

[realcool]

The ports what I talking about are ports of outgoing traffic, ephemeral ports for connections stablished by utorrent with other remote bittorrent client.

(When remote bittorrent clients connects to utorrent they do it to listening port of utorrent, a different port).

And I not want to use a range of ports for outgoing traffic, I am saying what utorrent when try to connect to other peer (utorrent makes connection, not the other peer) does NOT use certain ports (accept any ports given by windows except some specific ports).

I think it can be useful if you have a program that uses some ports (for example 1001, 1002 and 1025) and any of those ports are being used by utorrent when this program is launched.

If you tell to utorrent that never use ports 1001, 1002 and 1025 for any connection, the other program can be launched without problems if utorrent is already running.

At this time I have some problems to launch Java AppServer that uses many listening ports.

But never mind, I think the solution is use advanced option *net.outgoing_port* and set an unique port for outgoing connections. I didnt saw it before. It could affect speed of downloads?

NOTE: I have been able to see that utorrent uses following procedure to make connections.

format:

protocol local_ip:local_port remote_ip:remote_port status process_id prog_name

FOR INCOMING CONNECTIONS

1. set listening port (at utorrent startup, but I put here because is important)

TCP 0.0.0.0:6881 0.0.0.0:0 LISTENING 676 [utorrent.exe]

UDP 0.0.0.0:6881 *:* 676 [utorrent.exe]

2. utorrent receives a connection request (to its local listening port, in example is 6881)

TCP 192.1.0.1:6881 82.20.47.253:3744 SYN_RECEIVED 676 [utorrent.exe]

(note: computer of utorrent has ip 192.1.0.1 and listening port 6881)

(remote computer of other bittorrent client has ip 82.20.47.253 and try to connect from its port 3744)

3. If utorrent accepts connection, it is established

TCP 192.1.0.1:6881 82.20.47.253:3744 ESTABLISHED 676 [utorrent.exe]

FOR OUTGOING CONNECTIONS

1. utorrent sends a connection request to remote peer (to listening port of remote peer, in this example 22010).

utorrent do that from any port that is given by windows system of its computer (local system).

TCP 192.1.0.1:4541 201.236.186.26:22010 SYN_SENT 676 [utorrent.exe]

3. If the other peer accepts connection, it is established

TCP 192.1.0.1:4541 201.236.186.26:22010 ESTABLISHED 676 [utorrent.exe]

Well, in this case, if I launch a program that uses port 4541 to listen request (this port is its listening port), the program can not be launched.

In same case, if program's listening port is 6881, I just change this port in options of utorrent and then I will be ready to launch program with utorrent running.

This is the why I request a feature that tells to utorrent does not use port 4541, for example, for outgoing connections.

Note: I get this data from captures - using command "netstat" of windows (xp) with following syntax.

netstat -a -b -o -n > "filename".txt

You need to open a dos prompt windows to be able to see where "filename.txt" will be created.

[Switeck]

If you don't want µTorrent to use the ephemeral (local) ports for outgoing connections, then you'll have to use net.outgoing_port and net.outgoing_max_port.

You cannot exclude individual ports from the ephemeral range so µTorrent won't use them for outgoing. It's really not necessary since you can choose an outgoing port range anyway.

...Speaking of which, my outgoing port "range" only seems to be using my first outgoing port -- never above that.

[Firon]

You simply shouldn't be assigning programs to the ephemeral port range. It's very stupid, as ANY program making outgoing connections can take one of those ports.

µTorrent does it when starting with Windows by calling port 0, which lets Windows choose an open port in that range.

[realcool]

Yeah, with these two options Utorrent can set a new range of outgoing ports, the result would be the same that to exclude some ports, making unnecessary add something more.

On the other hand, some programs do not allow to set the ports that they use, for example, in Java AppServer an user can only set ports for administration and Web server (4848, 8080 and 8181), but the others (I could count 5 listening ports, 3 of them in range 1024-4999) come by default and to change them is very difficult. In cases like that this feature would be very useful.

Well, I will use the options given by Switeck, and with that add a new feature is not necessary.

This is the best, to not increase size of Utorrent.

Thanks.

[Switeck]

I worry more less about the probable increase in size that your suggestion would add but rather about the complexity and possibility for weird realtime conditions producing errors or exploits.

I've already heard about µTorrent's UPnP support failing due to ports-in-use problems. Trying to force µTorrent to ignore more than a handful of ports sounds like something that could cause slowdowns in the same way having a very long ipfilter.dat file can cause slowdowns.