Re: Win XP, Tor, and WSAENOBUFS

[Roger Dingledine <arma@xxxxxxx>]

On Sat, Apr 01, 2006 at 05:24:24PM -0500, Mike Chiussi wrote:
> The heart of the problem lies in that the Windows non-server kernel
> will allow users to "write" to a socket without ever reporting a
> problem until it's too late.

Is this actually true? Is there something we can do to confirm
it? Is this bug acknowledged by Microsoft? If so, do they have
suggested workarounds?

> I noticed in the bug report this doesn't
> happen when the user is running a server version of windows. The
> design philosophy for Windows server is to anticipate much more
> network activity, and devote physical resources to managing it, in
> contrast to Home edition which does not anticipate things like the
> kernel socket buffer being used up since it's only intended for
> lightweight network use.

Right. But there are some heavy programs that work on Windows XP. (At
least, I'm told they work.) For example, apache and various file-sharing
applications. Surely they end up with a case of several dozen sockets
trying to write and needing to buffer some of the data? How have they
resolved it?

> This might seem like a silly proposal, since I am still trying to
> understand the Tor source and coming to grips with Onion routing, but
> couldn't we modify the communication protocol slightly to include a
> provision where the client only sends a chunk data after the server
> has explicitly allowed it? Thus allowing the server to throttle its
> own incoming bandwidth while not having to buffer anything in kernel
> space. For example
> 
> S: Hello. Dont send me anything till I say so
> C: Okay
> S: Send 100kb
> C: (data)
> S: Send 100kb
> C: (data)

There are two problems with this approach. First, it requires us to
effectively rebuild TCP inside Tor. If we use a fixed-window approach
like you describe (always 100 KB at a time), then we can't adapt well
to available bandwidth and network congestion. Crippling performance on
all OSes just because one OS is flawed is probably not smart. Second,
how do we pick the number 100? If we have a bunch of sockets open, each
trying to push that amount, wouldn't that overfill the buffers too? If we
have no way to learn how much is too much, we still have a big problem.

--Roger