Subject: TCP send buffer free space
To: None <tech-net@netbsd.org>
From: Dave Gantose <gantose@grc.nasa.gov>
List: tech-net
Date: 07/09/2001 10:08:59
A few months ago, a question was posted here entitled "Determination of
TCP send buffer queue", but I don't see a response in the archives, and I
have a similar problem. To wit:

SHORT DESCRIPTION
I would like to be able to find out just how much free space is available
in the Send buffer of my TCP socket connection at a particular time.

LONG DESCRIPTION
Alternatively, maybe someone wiser than me can tell me  what I should
*really* do instead... I am writing a realtime data stream (from a data
generator) to this connection much of the time. Occasionally, I "replay"
an old data stream (from an archive file). These old messages are exactly
the same format as the realtime ones, and they must be sent through the
same socket connection, but since they are just being read from a file,
they are produced much more quickly, and they tend to fill up the TCP Send
buffer.

Now I wouldn't mind some delay in the *replayed* data getting to its
destination; using blocking I/O to write it to the socket, and letting TCP
manage the data flow would be just fine.

BUT, it is important that the *realtime* data be transmitted in a timely
manner, and I have not used blocking when writing that data to the socket
because I am afraid that a backup could cause bad things to happen "up the
line" (i.e., in the data generator itself).

So my thought is to only allow a replayed data message to be written to
the TCP socket if there is at least X amount of space left in the TCP Send
buffer. That way, I can assure there will be enough space for at least the
next N realtime messages to be written as they come in. (I realize that if
processing at the other end of the socket connection--over which I have no
control--is slow enough, then I'll eventually get into trouble at my end
anyway. I'm just trying to provide an optimum level of protection.) But
how do I find out if there is X free space left in the Send buffer?

Or what should I do instead?

Thanks in advance for any help and/or advice.

-- 
Dave Gantose 
Zin Technologies, Inc.
NASA John Glenn Research Center     phone: (216)977-0392 
3000 Aerospace Pkwy.            work stuff: gantose-work@bigfoot.com 
Brook Park, OH  44142          other stuff: gantose@bigfoot.com 
=====>> PGP Public Key available <<=====