On Tue, 20 Dec 2005 23:45:41 -0500
Phillip Susi <psusi(a)cfl.rr.com> wrote:
A correctly implemented TCP stack will keep sending
packets as long as
there is free space in the window. If the existing code refuses to send
more packets because there is SOME unacknowledged data, but enough room
in the window to send more, then it is broken.
The entire point of having a window is so that the sender can send
multiple packets before the first is ACK'd. Are you sure that the
existing code refuses to send even when the window should allow it? Or
is the window just too small? If so, are you sure it came directly from
the bsd stack? I can not believe that both are true.
Ge van Geldorp wrote:
Although I understand what's wrong, I have a
bit of difficulty trying to
figure out how to fix it. Attached is a proposed fix, which basically
attacks the problem at the sending end by removing the check if the
connection is idle or not. With that fix the loop.c program works as I
expect and
http://www.reactos.org loads in a much more reasonable 2-3 sec in
ibrowser. The problem that I have with the fix is that it's a change in code
we borrowed from the BSD stack. I can hardly imagine that a piece of
software so heavily used as the BSD stack would have such a fundamental
problem.
Any thoughts?
GvG
The problem is likely in our loopback pseudo adapter rather than
the BSD code, I'd guess.
It actually doesn't come directly from BSD. It was first in oskit,
in which some work was done to isolate a few parts of FreeBSD and
simplify and generalize the buffer management code. If there's
a mistake in the TCP implementation itself, I might have introduced
it. Since the IP and TCP code had stuff that overlaps code we
already had in tcpip.sys, I narrowed the scope of the BSD code
to make the import more compact (and preserve as much original
code as possible in ReactOS).
--
Here's a simple experiment. Stand on a train track between two
locomotives which are pushing on you with equal force in opposite
directions. You will exhibit no net motion. None the less, you may
soon begin to notice that something important is happening.
-- Robert Stirniman