Adrian> In article: <56ve2r$r7o@news-central.tiac.net>
Adrian> rlk@sunspot.tiac.net (Robert Krawitz) writes:
>> In article <903100wnr@realobj.co.uk> "Adrian St. John"
Adrian> <adrian@realobj.co.uk> 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
intervals.
regards,
./Pedro.