On Fri, Dec 19, 2008 at 7:54 AM, Lee <ler...@gmail.com> wrote: > ... > "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." > > seems backwards. Instead of buffering up to 16KB of data for each > open connection you're telling the system to buffer up to 1MB of data > for each open connection. How can increasing system buffer usage help > if the problem is insufficient buffer space?
this is a little odd. there is a different option useful for virtual servers (and seems to help with the WSAENOBUFS too) called ConstrainedSockets. this will use setsockopt() to limit the size of send and receive buffers associated with each socket. the ConstrainedSockSize parameter can lower or increase from the default constrained size. i wonder if the person reporting that behavior allowed TCP windows to scale above 1M so constraining them to 1M limit helped (but still seems high). > So I'm wondering if the problem could be that the system runs out of > available ports. i don't think this is quite as common, and is reported as an error distinct from the too many concurrent pending and buffer exhaustion errors. > XP defaults to using something like 4K ports and 240 seconds for > keeping a closed socket in the timed wait state. Has anyone tried > bumping the allowable port numbers up to 64K and dropped the timed > wait state time to 16 seconds? dropping the time wait state is a good idea. i have to do this for other connect heavy applications in a different setting to keep within global kernel limits for max open files. by default this is usually around 4 minutes. that's a long time to tie up scarce kernel buffer resources and/or file descriptors. i don't know how useful this would be for Tor servers; a good experiment for someone to try perhaps! :) best regards,