No subject

no registry hack to manipulate this buffer space.  It is a hard-coded
algorithm which is different between server and non-server editions of
Windows.  My numerous test using the /MAXMEM= boot option implied this
may be true.  

Squid is the first app I found that ran into this same situation in the
late 1990s with NT, and continued with Windows 2000.  A third party
re-wrote the squid code (aka ported) to use Windows standard calls.
This is where the idea of select() vs. overlapped I/O originated from,
as is eluded to on the
http://wiki.noreply.org/noreply/TheOnionRouter/WindowsBufferProblems
wiki page.  

I've done a lot of testing with various versions of Tor as an exit
server on my WinXP Home machine.  If anyone is so inclined to peruse it, I have a 4GB
output file from strace for NT wrapping Tor until it hits the problem.  

Interesting that Azureus and some other win32-native bittorrent client
never hit the WSAENOBUFS errors.  

Regardless of what Microsoft may or may not do to generate revenue
between server and client versions of Windows, many TCP intensive
programs never hit the WSAENOBUFS error.  I can think of a few P2P
programs (emule, limewire, edonkey) that never hit WSAENOBUFS, yet would
easily manage thousands of tcp connections.  Azureus runs inside the
JVM, and in my tests, I shared up the latest debian, centos, and ubuntu
isos on a 100 Mb/s connection to the 'net.  The connection would get
very busy, yet Win XP Home would crank along just fine. A netstat -an
would return thousands of lines.  

One final thought, many educational institutions around the world have
access to Windows source code.  Can we find these and/or ask someone at
Microsoft to poke through the code and see when WSAENOBUFS is generated?
This would at least get us a start.

-- 
Andrew