In message <200107101933.PAA25056@lombok-fi.lerc.nasa.gov>Dave Gantose writes
>-- Jonathan Stone wrote:

[...]


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

But how much is "a lot"? The anwer depends on how long it takes the
data to get to the recveiving TCP and for the ACK to come back.  All
that data is "in flight" until you get the ACK.

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


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

`That plan never works", as you realize below.

[...]


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

Yep. thats why a better design is to expose, all the way to the
"master controller", which  of your traffic is realtime. 

So, that if you get unlucky and send a full TCP window to the master
controller just as the master-controller gets bogged down, the
realtime traffic doesn't have to wait.

If managemenet considerations make that impossible, you could always
try kludging up a socket option: define SO_SNDSPACE, and add code 
sys/kern/uipc_socket.c:sogetopt() to implement it. 

What you want is sbspace(so->so_snd). Add an entry to the switch
which returns that, build a new kernel, and presto.