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