Tracker Status: Offline (Timed Out)

[Mastro]

Well at first I thought it was my tracker that I use, then I thought it was me, now I'm more convinced it's uTorrent.

I have abot 45 torrents loaded on my client and just the other day they started to turn red, with Tracker Status: offline (timed out). Then after x amount of time they will turn green again, and then as they turn green they will go red again. It's the same problem with multiple trackers, so it's something related to myself, uTorrent my connection.

I'm confident it's not my firewall.

Has anyone else expereinced this problem after running say 30+ torrents? That they trackers "time out".

Why I think it's uTorrent? If I close the client and re-open it, my torrents all start to turn green again. Then after 16 or so torrents, I start getting the error again.

Thoughts? I would really like to narrow it down. I'm going to download another torrent client and see how that performs.

[Ultima]

Check the first link in my signature.

[Mastro]

Thanks. Curious, what does "Lowering net.max_halfopen to 4" do?

I also did this: http://wiki.noreply.org/noreply/TheOnionRouter/WindowsBufferProblems

To do this go to Start, Run and type regedit. In the left pane navigate to

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters once

there, you must create the entry TcpNumConnections. To do this, right click in

the right pane and choose new from the menu and select DWORD Value. Give it the

name TcpNumConnections. Then right click it and select modify and enter a value

of 800. Then restart your computer.

There are a few TCP related registry entries that potentially manipulate the internal buffer size available for data to be passed through the tcp stack. Manipulating HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\GlobalMaxTcpWindowSize and TcpWindowSize to 0xfaf00 (1027840) seemed to increase the time to failure when running Tor and BitTorrent.

Configuring HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts="3" also seemed to help the exit server last longer. Setting this to "1" is another option as it doesn't remove 12-bytes from every header for timestamp placement. However, Tor seems to have lots of odd packet problems on an exit server (as shown by ethereal, lots of re-transmits, lost ACKs, etc), and the "3" solution seemed to quiet these things down. (Only packet headers were captured during the tests, not actual data.)

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\SackOpts="1" is another helpful setting.

[Ultima]

Don't bother messing with the registry settings. Lowering net.max_halfopen lowers the chance that you're reaching the half open limit imposed by XP SP2.