Jump to content

Function Of The "listening" Port In A Proxied Setup


AuContraire

Recommended Posts

I use BitTorrent latest version. I create an ssh tunnel to a proxy server for my whole computer on port 1080. I set the network preferences for the whole computer to localhost:1080 and I set the proxy preference in BitTorrent to localhost:1080 also.

I use a couple of different sniffers to confirm that the public IP of the whole computer, and the public IP of the BitTorrent client are indeed the IP of the proxy server. I am therefore "in the blind" and in an encrypted tunnel as far as my ISP and as far as the rest of the world is concerned, as far as I can see.

As additional confirmation: I get huge transfer speeds, much faster than when in an un-proxied state. This I put down to the suspicion that my ISP uses deep packet inspection to identify and throttle torrent traffic, but because this traffic is in an ssh tunnel it can't be identified so they don't slow it down

QUESTION: The "listening" port is randomly selected and in a high number range. How exactly does the "listening" port function? What exactly is it doing? Is it proxied through the same port I forwarded to my proxy server for the whole computer? If not, why do uploads still work? I am reasonably informed in network theory so a technical answer doesn't scare me too much!

Link to comment
Share on other sites

Thanks for the quick reply. Just trying to drill down a little and understand what's going on under the hood, to mix a metaphor. My understanding is that, when I add a torrent to BitTorrent it makes an announce to any IP that is listed in a tracker or a DHT as having those files. Since my client is bound to proxy localhost:1080 which is in turn tunneling to a remote server, that's the route the announce takes and the replies come back the same way. I then form connections, both peer to peer and peer to seed, which work fine in both directions. The green light indicating that incoming connections are working is always on

My understanding is that each of those connections requires a port open on my local device, but that's no problem because all those ports are behind my localhost:1080 proxy so the whole arrangement works fine

The problem seems to come with pure incoming connections where my client did not initiate the connection. I believe in these cases the listening port hears the announce from a remote peer and attempts to form a connection but, since it needs to open a port to do so, and that port winds up being on the remote server, not on my local device. The remote server doesn't seem at all happy to comply with requests to open ports in this way, and I sort of don't blame it! This doesn't hurt me any, but it's not in the spirit of file sharing and I would like to find a way to cause the remote server to allow these ports to be opened, if I can

Have I got the sequence basically correct?

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...