The WindowsBufferProblems

[Ge van Geldorp]

> From: Mike Chiussi
> 
> On second thought we should have this discussion over or-dev, 
> just so anyone else can learn from it or share their ideas.

Yes, makes sense.

> You probably haven't been online long enough. For reasons 
> that I'm still not clear on, Tor clients don't "trust" 
> servers that have a short uptime.
> 
> A trick is to open up a DirPort, this will draw a lot of 
> connections, my torrc is here http://www.cdf.toronto.edu/~g4mike/torrc
> 
> Here is a netstat -n from my system taken briefly after the 
> first wsaenobufs incident i noticed.
> http://www.cdf.toronto.edu/~g4mike/netstat

Ok, looking at your files, the biggest difference is probably that you're
running as an exit node and I'm strictly middle-man (my testnode is "gvg4"
btw). I've opened my DirPort.

If I interpret your netstat output correctly, you were basically only
running Tor and no other network-intensive apps. The number of Tor
connections was rather small, I've seen a few hundred on my test system
without problems.

The other thing that jumps out to me is that you have 10 connections in
SYN_SENT (half-opened) state. The Wiki page says there's a limit of 10
half-open connections per second. If that limit is hit it should give a
different errorcode though. Still, it's just a little bit too much of a
coincidence. Any "EventID 4226" events in your Event Log?

> I haven't yet experimented with the registry yet, however I 
> don't think that is going to help. My understanding (I might 
> be wrong here) is that there is a fairly large amount of 
> space available in the NPP, but Windows puts a limit per 
> process with the exception of localhost traffic. For example, 
> when first getting into this I tried writing aserver which 
> accepted connections and a client which did nothing but 
> connect and write (all traffic was local). note, the server 
> never read from the clients the goal was to fill up the NPP. 
> I didn't start getting wsaenobufs errors until NP usage was 
> around 40 megabytes.
> However, Tor would generate wsaenobufs at around 4-5 megabyes 
> of usage.

If it starts to generate WSAENOBUFs at 4-5 MB of nppool usage, I'm starting
to wonder if this is nppool related. Even on a system with 96Mb of physical
RAM, nppool should be able to grow to around 38Mb.

Kernel components can allocate nonpaged pool using one of two routines,
ExAllocatePoolWithTag and ExAllocatePoolWithQuotaTag. The
ExAllocatePoolWithTag routine doesn't impose a maximum per process, while
the ExAllocatePoolWithQuotaTag does. I'm under the impression that AFD.SYS
and TCPIP.SYS (the networking drivers) use ExAllocatePoolWithTag (so no
maximum per process). I tried the same experiment as you (writing a server
and a client), but I also tried with the client running on a different
computer (so using a "real" network interface, not loopback). In both cases
I'd be able to completely exhaust nppool. This would be impossible if
AFD.SYS/TCPIP.SYS used ExAllocatePoolWithQuotaTag.

Gé van Geldorp.