Subject: Re: TCP send buffer free space
To: None <email@example.com>
From: David Brownlee <firstname.lastname@example.org>
Date: 07/09/2001 15:28:11
One option might be to have two sockets between the client and
server - one for realtime and one for playback. Could simplify
logic considerably :)
David/absolute -- www.netbsd.org: No hype required --
On Mon, 9 Jul 2001, Dave Gantose wrote:
> 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
> 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.