[lkml]   [1996]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: TCP buffer problem with 2.1.11

In article: <56ve2r$>
(Robert Krawitz) writes:
> In article <> "Adrian St. John"
<> 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
> within the kernel until the write buffer is full, at which point
> 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.

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

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

Perhaps a clarification of the situation:

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

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

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

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

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

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

Just to re-iterate, this problem does not occur when running the server
process (identical code) on a SPARC-Solaris box.

Any more comments?

Thanks in advance,

Adrian St. John.

Adrian St. John
Real Objects Ltd, Leamington Spa, England
Phone: +44 (0)1926 833488

 \ /
  Last update: 2005-03-22 13:38    [W:0.055 / U:0.768 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site