Re: TCP buffer problem with 2.1.11

Pedro Roque (
Thu, 21 Nov 1996 11:08:07 GMT

>>>>> "Adrian" == Adrian St John <> writes:

Adrian> In article: <56ve2r$>
Adrian> (Robert Krawitz) writes:
>> In article <> "Adrian St. John"
Adrian> <> writes:
>> This works smoothly to start off with, until the recv buffer
>> on the Linux box becomes full, at which point all write
>> operations get
Adrian> queued
>> within the kernel until the write buffer is full, at which
>> point
Adrian> the
>> buffer is emptied.
>> Have you tried setting TCP_NODELAY on the write socket? You
>> might be running into the Nagle algorithm with this kind of
>> setup.

Adrian> All my sockets have TCP_NODELAY set on them. If the Nagle
Adrian> algorithm is coming into affect, then it seems to be
Adrian> pretty brain-damaged if it doesn't flush the buffers on a
Adrian> more-regular basis, rather than every 6-7 minutes (50
Adrian> bytes at 5 second intervals are written by my process).

Adrian> Also, this doesn't explain why the whole thing works
Adrian> properly to start with, as the data is sent immediately.

Adrian> Perhaps a clarification of the situation:

Adrian> The connection between the two machines is TCP-socket
Adrian> based.

Adrian> My 'data-packets' are *NOT* datagrams, but lumps of data
Adrian> on the stream, which in this case happen to be around 50
Adrian> bytes each.

Adrian> TCP_NODELAY is set on the sockets at each end, so data
Adrian> should be written across the network as soon as possible
Adrian> (without going through the Nagle)

Adrian> The bug only occurs AFTER I fill the kernel recv-queue on
Adrian> the Linux box by sending data from the NT box faster than
Adrian> the process on the Linux box reads it.

Adrian> The NT box is constantly performing a select() on the
Adrian> connection, so once there is data to be read it will read
Adrian> it.

Adrian> Also, the Linux box doesn't re-fill the kernel recv-queue
Adrian> until my process has totally emptied it.

That means for sure that the NT box doesn't send more data.
I'm not puting apart the chance we might have a bug on the socket handling
code but if you receive data on a connection then it will apear on
the recv-queue numbers.

Please use tcpdump or snoop to look what is going on in the network.

Note that when your recv-queue fills Linux will signal a 0 window back to
the sender. The sender then has to probe the receiver in exponential rto