Messages in this thread | | | Date | Thu, 21 Nov 1996 11:08:07 GMT | From | Pedro Roque <> | Subject | Re: TCP buffer problem with 2.1.11 |
| |
>>>>> "Adrian" == Adrian St John <adrian@realobj.co.uk> writes:
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.
| |