Question regarding how Ktorrent uses ports...

When you specify the PORT to use with Ktorrent, Ktorrent seems to work differently than I would expect, and different from uTorrent (popular on the other OS platform).

For example, say that you specify Port 20000 as your port.

- with uTorrent, it actually SENDS & RECEIVES on THAT port, which is great, because it is predictable. This makes a BIG difference if you want to use PORT TRIGGERING on a NAT router instead of STATIC PORT FORWARDING, which can be a pain with changing IP addresses, multiple computers behind the NAT will each need a different port forwarded, etc. Since SENDING on this port is happening, Port Triggering will RELIABLY occur, keeping Port 20000 open both directions as long as uTorrent is running, regardless of whether you are downloading-only, seeding-only, or doing both.

- with Ktorrent, apparently all the port is doing is listening/receiving?? The problem with this behavior is that without anything being SENT from this port, the NAT port triggering never takes place, thus keeping port 20000 (in this example) CLOSED.

For example, see these Netstat's which occurred as fast as I could reboot the PC into different OS partitions, netstat run after approx 30 seconds of launching the application:

[XP with uTorrent, XP firewall with port 20000 open]

netstat -an
Active Connections

Proto Local Address Foreign Address State
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:20000 0.0.0.0:0 LISTENING
TCP 192.168.101.20:3987 68.1.239.130:6884 SYN_SENT
TCP 192.168.101.20:3988 68.64.100.110:6346 SYN_SENT
TCP 192.168.101.20:3989 24.191.97.45:50000 SYN_SENT
TCP 192.168.101.20:3991 68.97.163.119:6882 SYN_SENT
TCP 192.168.101.20:3993 69.163.22.48:6777 SYN_SENT
TCP 192.168.101.20:3994 68.226.211.47:6882 SYN_SENT
TCP 192.168.101.20:3995 24.238.177.55:16881 SYN_SENT
TCP 192.168.101.20:3997 67.177.85.246:50506 SYN_SENT
TCP 192.168.101.20:3998 67.163.244.94:49153 SYN_SENT
TCP 192.168.101.20:3999 82.111.95.158:1234 SYN_SENT
TCP 192.168.101.20:20000 12.182.42.193:2500 ESTABLISHED
TCP 192.168.101.20:20000 24.6.172.20:4353 TIME_WAIT
TCP 192.168.101.20:20000 24.191.97.45:2031 TIME_WAIT
TCP 192.168.101.20:20000 24.226.225.110:61705 ESTABLISHED
TCP 192.168.101.20:20000 24.226.225.110:61714 TIME_WAIT
TCP 192.168.101.20:20000 24.226.225.110:61729 TIME_WAIT
TCP 192.168.101.20:20000 24.226.225.110:61763 TIME_WAIT
TCP 192.168.101.20:20000 24.226.225.110:61772 TIME_WAIT
TCP 192.168.101.20:20000 65.93.134.153:1942 TIME_WAIT
TCP 192.168.101.20:20000 65.93.134.153:1972 TIME_WAIT
TCP 192.168.101.20:20000 66.24.226.20:61031 ESTABLISHED
TCP 192.168.101.20:20000 66.57.99.123:51350 TIME_WAIT
TCP 192.168.101.20:20000 66.57.99.123:51375 TIME_WAIT
TCP 192.168.101.20:20000 66.58.197.39:33069 TIME_WAIT
TCP 192.168.101.20:20000 66.58.197.39:33233 ESTABLISHED
TCP 192.168.101.20:20000 66.58.197.39:33291 ESTABLISHED
TCP 192.168.101.20:20000 66.58.197.39:33315 ESTABLISHED
TCP 192.168.101.20:20000 66.58.197.39:33363 ESTABLISHED
TCP 192.168.101.20:20000 66.58.197.39:33375 ESTABLISHED
TCP 192.168.101.20:20000 66.58.197.39:33441 ESTABLISHED
TCP 192.168.101.20:20000 67.41.120.196:2239 TIME_WAIT
TCP 192.168.101.20:20000 67.139.154.178:47428 TIME_WAIT
TCP 192.168.101.20:20000 68.203.119.178:35213 TIME_WAIT
TCP 192.168.101.20:20000 68.203.119.178:35243 ESTABLISHED
TCP 192.168.101.20:20000 69.76.197.53:4309 TIME_WAIT
TCP 192.168.101.20:20000 69.235.132.143:60300 TIME_WAIT
TCP 192.168.101.20:20000 72.192.198.113:61571 TIME_WAIT
TCP 192.168.101.20:20000 129.44.74.44:63994 TIME_WAIT
TCP 192.168.101.20:20000 132.198.240.240:1905 ESTABLISHED
TCP 192.168.101.20:20000 136.165.144.149:3785 TIME_WAIT
TCP 192.168.101.20:20000 166.82.151.241:1088 TIME_WAIT
TCP 192.168.101.20:20000 166.82.151.241:1102 TIME_WAIT
TCP 192.168.101.20:20000 166.82.151.241:1115 TIME_WAIT
TCP 192.168.101.20:20000 166.82.151.241:1127 TIME_WAIT
TCP 192.168.101.20:20000 166.82.151.241:1134 TIME_WAIT
TCP 192.168.101.20:20000 205.243.119.141:2995 ESTABLISHED
TCP 192.168.101.20:20000 216.27.220.50:12350 ESTABLISHED
UDP 0.0.0.0:445 *:*
UDP 0.0.0.0:1026 *:*
UDP 0.0.0.0:1106 *:*
UDP 0.0.0.0:2525 *:*
UDP 0.0.0.0:2526 *:*
UDP 0.0.0.0:2527 *:*
UDP 0.0.0.0:3243 *:*
UDP 0.0.0.0:3244 *:*
UDP 0.0.0.0:3245 *:*
UDP 0.0.0.0:20000 *:*
UDP 127.0.0.1:1025 *:*


[Suse 10.0, suse firewall with port 20000 open]

netstat -tupan | grep "ktorrent"
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)

tcp 0 0 0.0.0.0:20000 0.0.0.0:* LISTEN 16335/ktorrent
tcp 0 0 192.168.101.20:9680 70.254.242.1:59395 ESTABLISHED 16335/ktorrent
tcp 0 0 192.168.101.20:1895 81.179.108.250:16881 ESTABLISHED 16335/ktorrent
tcp 0 0 192.168.101.20:13481 65.93.134.153:6881 ESTABLISHED 16335/ktorrent
tcp 0 0 192.168.101.20:16508 207.6.155.166:32460 ESTABLISHED 16335/ktorrent
tcp 0 0 192.168.101.20:15111 24.34.179.13:6881 ESTABLISHED 16335/ktorrent
tcp 0 0 192.168.101.20:11000 66.54.207.127:55555 ESTABLISHED 16335/ktorrent
tcp 0 0 192.168.101.20:2856 72.192.198.113:45232 ESTABLISHED 16335/ktorrent


I realize that static port forwarding on the NAT router is the traditional way to do this, and while testing Ktorrent over the past week I have been using port forwarding until today,... but (a) there is really no reason for static port forwarding to be necessary, see the uTorrent example above, (b) it requires at least 1 port to be OPEN ALL THE TIME regardless of whether any Torrent client is running or not, whereas reliable outbound triggering will allow the port to quickly close when the torrent client is closed (since no triggering is taking place), and (c) static forwarding is much less convenient when using multiple PC's behind a NAT router.

Just wondering what your thoughts are on this topic, and whether you see any merit in the examples and alternative design explained above.

regards...

Let me get this straight, µTorrent manages to send all data over one TCP connection to multiple hosts ????

That is impossible, a TCP connection is point to point, if you are connected to 700 peers you need 700 different TCP connections.