Win XP, Tor, and WSAENOBUFS

[Roger Dingledine <arma@xxxxxxx>]

I'm forwarding a thread about Tor and Windows that I've been having
with Mike Chiussi. Hopefully opening it up to the other developers will
spark other thoughts -- and this way it gets archived in a way that we
can reference.

The issue we're talking about is the fact that Tor servers on XP crash:
http://wiki.noreply.org/noreply/TheOnionRouter/WindowsBufferProblems

--Roger

----- Forwarded message from Roger Dingledine <arma@xxxxxxx> -----

From: Roger Dingledine <arma@xxxxxxx>
To: Mike Chiussi <chiussi@xxxxxxxxx>
Subject: Re: Win XP, Tor, and WSAENOBUFS
Delivery-Date: Fri, 31 Mar 2006 19:22:47 -0500

On Mon, Mar 27, 2006 at 12:30:56PM -0500, Mike Chiussi wrote:
> >  I'm beginning to guess it's not a three-line fix.
> 
> It probably isn't, but it just might be. The first thing I would do is
> trace through the code every between accept() and recv() and ensure
> that no socket is being starved. Again, this seems to be the most
> likely cause to me.

On thinking about it more, this could well be part of the issue.

Peter (another Tor developer) suggested that this starvation occurs when
we stop reading on a socket. You see, that's how Tor does rate limiting:
when it wants to slow things down, it stops reading. This causes TCP
pushback, the other side stops sending, and we're in business. Unless
the kernel can't buffer things and dies.

But this isn't the problem here, because even Tor servers that don't
enable rate limiting (that is, that never stop reading) have some
problem. But if they *did* enable rate limiting, this may come into play.

But here's another place where it could happen, and this could help
explain what we see currently. If *other* Tor servers stop reading,
then after a point we can't write to them anymore. Are these same
kernel buffers getting filled in this case?

If this is in fact the problem, is there a way to tell Tor not to try to
send the data until it would be ok to write it? In my little Posix world,
that's what the write() call is *for*: if it succeeds then the kernel is
willing to buffer it, and if it returns EAGAIN then you try again later.
Perhaps Windows has a more complex approach, to workaround the flaw
that the kernel is willing to bite off more than it can chew?

--Roger

----- End forwarded message -----