[Live-devel] Forcing TCP packets to send immediately from server

[Ross Finlayson]

> On Jun 4, 2024, at 5:39 PM, Paul Westlund <paul.westlund at currentcorp.com> wrote:
> 
> Is there some way that setting TCP_NODELAY could be incorporated into LIVE555, maybe as a build option similar to the REUSE_FOR_TCP macro?

I don’t know what “REUSE_FOR_TCP” is.  There’s no such macro used in our code.

In principle we could set TCP_NODELAY on the RTSP (TCP) socket, but I don’t want to do this, because it would increase the number of network packets, and potentially increase network congestion.  Unfortunately people often use RTP/RTCP-over-TCP streaming over networks where the effective bitrate of the network (taking into account delay and packet-loss frequency) is close to (or, in the worst case, lower than!) the natural bitrate of the stream - which already produces network congestion.  This would make it even worse.

Also, as you noted, this isn’t really needed, because the data is already being delivered correctly, with correct presentation times.  The receiver should already be buffering incoming data in a jitter buffer - which would probably produce the same average net latency as seen by the renderer.


> Or can the socket properties be modified outside of the LIVE555 library?

If you really wanted to, you could access the socket for each client connection by subclassing “RTSPServer” and “RTSPClientConnection” and reimplementing the virtual function “createNewClientConnection()"; the (protected) field “ClientConnection::fOurSocket” could be accessed by your “RTSPClientConnection” subclass (i.e., you could set TCP_NODELAY in its constructor). 

But you should really ask yourself why you are requesting RTP/RTCP-over-TCP streaming.  This is a hack, which should be used *only* if you have a firewall somewhere - between the server and client - that blocks UDP packets (and which can’t be fixed).  You should try to avoid doing this if possible,


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/