Re: Win XP, Tor, and WSAENOBUFS

[Roger Dingledine <arma@xxxxxxx>]

...and Mike's response.

----- Forwarded message from Mike Chiussi <chiussi@xxxxxxxxx> -----

From: Mike Chiussi <chiussi@xxxxxxxxx>
To: tor-assistants@xxxxxxxxxxxxx
Subject: Re: Win XP, Tor, and WSAENOBUFS
Delivery-Date: Sat, 01 Apr 2006 15:19:32 -0500
>
> 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?

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. 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.

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)
C: Thats all
S: Bye!

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