(FWD) Re: Win XP, Tor, and WSAENOBUFS

[Roger Dingledine <arma@xxxxxxx>]

[And a response from Mike. Mike, it may be more efficient for you to drop
by the irc channel (#tor at irc.oftc.net) and we can talk more if we're
both there. What I'm describing is typical TCP behavior -- at least,
I think it is. :) -RD]

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

Date: Sun, 2 Apr 2006 15:33:23 -0400
From: Mike Chiussi <chiussi@xxxxxxxxx>
To: or-dev@xxxxxxxxxxxxx
Subject: Re: Win XP, Tor, and WSAENOBUFS

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

Let's use BitTorrent software as an example. When the client desires a
file, it connects to someone we know that has it. We explicitly ask
for every chunk of the file to be sent to us. And since each chunk is
rather small it gives the software the ability to control the download
rate.

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

It might need rebuilding then. It seems that this method of throttling
downloading wasn't the best choice to begin with. I want to be very
clear that I understand your approach correctly. The server wants to
control the rate at which data is received, so it lets a kernel buffer
hold the data until it fills up, then the server will report an error
to the client (triggered in the kernel) . If I understood this
correctly, the problem lies in the assumption that the OS will
actually send the error - I don't believe it's required to. A well
designed Unix kernel might report an error to the client when this
buffer is filling up, that doesn't mean it's required under Posix. And
I doubt the Windows specification requires it either. (Since I have
never come across a means of capping a download rate via a socket
option, on any system)

I used 100kb as an example window size. The window size would be a
function of the current clients anticipated upload rate and how much
space we think we have left in the buffer.

-Mike

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