Date:	Sat, 21 Oct 2000 12:35:30 +0100 (MET)
From:	Gisle Vanem <giva AT bgnett DOT no>
To:	djgpp AT delorie DOT com
Subject:	Re: libsocket: problems with receiving large amount of data
In-Reply-To:	<8srp88$7tj$01$1@news.t-online.com>
Message-ID:	<Pine.UW2.3.95.1001021122111.9812A-100000@bryggen.bgnett.no>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Sat, 21 Oct 2000, Peter Remmers wrote:

> Hi!
> 
> I'm currently writing a telnet program and now have the problem
> that when I receive a relatively large amount of data (such as
> with "ls -lR /") after a few seconds it hangs, because
> the library thinks there is no data to read.
> select() hangs (or times out), recv() either blocks (blocking
> mode) or fails with EAGAIN (nonblocking).

This seems a typical result of the "closed window" syndrome. 
I.e. the receiver buffer is overflooded and the window (in the 
tcp-header) shrinks rapidly down to zero. The sender should
in this case "back-off" waiting for the receiver's window to open
again.

I suspect the application on the sending side isn't correctly handling 
the send() fail (errno=EAGAIN?) in this case. The sending loop exits
and the effect is what you see.

> On my linux box (where I do the "ls -lR /") netstat says the
> send-Q of the connetion fills up to like 40k or so.

Because the Winsock (?) isn't opening the tcp-window again *OR* the 
application isn't flushing it's receive-buffer.

All in all, the fault could be on either side (but it's hard to believe
Winsock solely is to blame). You should use tcpdump or similar tools
to see exactly whats going on.   

Gisle V.

- Raw text -