Have the client ACK every N units of playback data. Allows you to
	guarantee no more than N units of replay data in front of new
	realtime data... Tune N to taste :)

-- 
		David/absolute		-- www.netbsd.org: No hype required --


On Mon, 9 Jul 2001, Dave Gantose wrote:

> I would love to have two separate sockets, but this is a Space Station
> project and the single socket has been dictated to us from on high :(
>
> -- David Brownlee wrote:
>
> >     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
> >> 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.
> >>
> >>
>
>
>
>