-- Jonathan Stone wrote:
> 
> In message <x7g0c6q8d9.fsf@capsicum.wsrcc.com>,
> Wolfgang Rupprecht writes:
> 
> 
>>Figuring out how many packets are in the kernels local queue doesn't
>>tell you how many packets are in flight.  You could (and almost
>>certainly will) have a data backlog at the point where a big pipe gets
>>attached to a small pipe (typically the WAN link.)
> 
> In general,, there could be an entire TCP window's worth of
> data in flight. up to bandwidth* delay.

I don't think the amount of data in flight matters to me since packets do
not get removed from my Send buffer until ACKed by the remote TCP.
I simply want to know how much *free space* is in my TCP Send buffer--if
there is only a little, then I should reserve it for the more-important
realtime data, but if there is alot, then I can safely write some
less-important playback data into it.

> With quantitative numbers on the RTT and the advertised TCP buffer
> to the "master controller", we could give more helpful advice.

I do not know these things at this time.

> Maybe setting the socket into non-blocking mode for the playback data
> (and buffering any non-realtime messages which get an EWOULDBLOCK) and
> setting it back into blocking mode for realtime messages, would be good enough.

My problem in this case is that there are two separate processes (one for
each type of data). They would be setting the same socket connection to
two different states (blocking or non) and might interact badly with one
another....Explaining it so makes me realize it shouldn't be this way; I
should have a single process or thread managing the socket connection with
an intermediate buffer (or two) for catching the incoming realtime or
playback data. Perhaps I will follow this path for awhile.

> Depends on the network characteristics (and how promptly the master
> controller reads the from its TCP receive buffer).

Much depends on that processing at the far end of the connection. If it
is slow enough or bogs down long enough, there will be nothing I can do to
avoid problems. That's just how it is...



--