• Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About AuContraire

  • Rank
    New User
  1. This whole question of speeds, both up and down, in the world of torrents is (one of) the most discussed and least understood. Speeds both up and down are affected by a wide range of factors, including but not limited to: ~the quality of your own network, wireless, wired Ethernet? ~the theoretical speed of the service you have subscribed to from your ISP ~the practical "data delivery" speed of the same connection after overheads, bandwidth shaping etc are factored out ~the fact that all (virtually) Internet connections are MUCH slower on the upload side than on the download ~the quality of the swarm. Ironically, a swarm in which there are a hundred seeds might literally never call on a peer with only 10% of a file to upload at all Etc etc It takes experience with a lot of files, and fooling around with a lot of freely available utilities, to measure these things and come to an understanding of what is really happening in your case
  2. 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?
  3. 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!
  4. Here is a response from BTGuard itself which solved a similar problem for me: - For Windows DNS settings are specified in the TCP/IP Properties window for the selected network connection. 1. Go the Control Panel. 2. Click Network and Internet, then Network and Sharing Center, and click Change adapter settings. 3. Select the connection you use. For example: - To change the settings for an Ethernet connection, right-click Local Area Connection, and click Properties. - To change the settings for a wireless connection, right-click Wireless Network Connection, and click Properties. If you are prompted for an administrator password or confirmation, type the password or provide confirmation. 4. Select the Networking tab. Under This connection uses the following items, select Internet Protocol Version 4 (TCP/IPv4) and then click Properties. 5. Click Advanced and select the DNS tab. If there are any DNS server IP addresses listed there, write them down for future reference, and remove them from this window. 6. Click OK. 7. Select Use the following DNS server addresses. If there are any IP addresses listed in the Preferred DNS server or Alternate DNS server, write them down for future reference. 8. Replace those addresses with the IP addresses of the Google DNS or OpenDNS servers: - For IPv4: or or or 9. Restart the connection you selected in step 3. 10. Repeat the procedure for additional network connections you want to change. - For Mac OSX DNS settings are specified in the Network window. 1. From the Apple menu, click System Preferences, then click Network. 2. If the lock icon in the lower left-hand corner of the window is locked, click the icon to make changes, and when prompted to authenticate, enter your password. 3. Select the connection you use. For example: - To change the settings for an Ethernet connection, select Built-In Ethernet, and click Advanced. - To change the settings for a wireless connection, select Airport, and click Advanced. 4. Select the DNS tab. 5. Click + to replace any listed addresses with, or add, the Google IP or OpenDNS addresses at the top of the list: - For IPv4: or or or 6. Click Apply and OK. 7. Repeat the procedure for additional network connections you want to change.