Subject: Re: TCP send buffer free space
To: Wolfgang Rupprecht <wolfgang+gnus20010709T105800@wsrcc.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 07/09/2001 13:54:52
In message <firstname.lastname@example.org>,
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.
If it's on the space station, there may not be a WAN link: depends if
the 'master controller' is sending the data over to some MIL-SPEC-1750
drain-bamage, or to a TDRSS link, or something else.
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.
Depends on the network characteristics (and how promptly the master
controller reads the from its TCP receive buffer).