Yes, another reasonable suggestion. Unfortunately, I have no control over
the client. The spec says to establish this one server socket. The master
controller will then make a connection and accept and forward my messages
to the (single) final destination.

By the way, to the master controller, a playback packet looks the same as
a realtime packet. So even if it were willing to help with flow control of
playback data (which it is not), it couldn't tell the difference.

I *could* just hardcode some slow-down factor into the playback data
process. That is, send a little, sleep a little, send a little, sleep a
little,... But that seems so inflexible--and inefficient if the bandwidth
is not being used for other things.

Dave Gantose
Zin Tech

-- David Brownlee wrote:

>     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.
>> >>
>> >>
>>
>>
>>
>>



--