[Live-devel] Possible bug in RTPInterface::sendDataOverTCP

[Ross Finlayson]

> I tried to fix the problem by this way:
> 
> -      sendResult = send(socketNum, (char const*)(&data[numBytesSentSoFar]), numBytesRemainingToSend, 0/*flags*/);
> +      
> +      do {
> +           sendResult = send(socketNum, (char const*)(&data[numBytesSentSoFar]), numBytesRemainingToSend, 0/*flags*/);
> +      } while(sendResult == -1 && envir().getErrno() == EAGAIN);

No, you can't do this (and there's not a 'problem' that needs fixing)!  If the TCP connection gets blocked permanently (e.g., because the receiving client has stopped running, or has a cable disconnected), then you can't just sit in a loop, attempting to send() over and over again.  That would starve out all other server activity.

There's no 'bug' or 'problem' here.  The "EAGAIN" error occurs when the sending OS's TCP buffer is full - which occurs if the stream's bitrate exceeds (at least temporarily) the capacity of the TCP connection.  When this happens, the only solution is to discard outgoing data.  Our code does so by ensuring that if/when data gets discarded, the discarded data will be a complete RTP (or RTCP) packet - equivalent to the loss of a packet if you were streaming over UDP.

Some people seem to think that streaming over TCP is a 'magic wand' that will avoid all data loss, regardless of the bitrate of your stream and the capacity of your network.  But that's impossible.  If your stream's bitrate exceeds the capacity of your network, you *will* lose data.  The only way to prevent this is either to transmit a slower stream, or use a faster network.

Yet again, let me remind everyone that streaming over TCP is something that you should be doing *only* if you are behind a firewall that blocks UDP packets

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20140919/34d306f9/attachment.html>