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



--