[Live-devel] When streaming RTP over TCP, Live555 Proxy Server sometimes does not reconnect to 'back end' device

[Erik Montnemery]

> This error is always caused by a socket being closed without
>         disableBackgroundHandling()
> or, equivalently
>         turnOffBackgroundReadHandling()
> having been first called on it.
As I understand it, the socket is properly closed, but the (now closed)
socket number is incorrectly reused when a client of the proxy issues a PLAY.

I've attached an example log where this happens in case it is useful.
Note: there are a lot of added debug prints

A short summary of the log:
Line    1: Connection to 'back-end' server opened on socket 13
Line  468: Line 828: Socket number (13) is used by four RTPInterface,
all related to connection between 'back-end' server and RTSP Proxy, 2
subsessions, RTP and RTCP for each session.
Line 1781: RTPInterface::stopNetworkReading called on one of the
RTPInterface instances
Line 1846: Error is detected by RTPInterface::sendDataOverTCP. This
causes RTPInterface::removeStreamSocket to be called for three, but
not the last, RTPInterface (0x36f5110) from SocketDescriptor
destructor and the socket (13) to be closed. The reason for
RTPInterface::removeStreamSocket not being called on the last
RTPInterface is that RTPInterface::stopNetworkReading was previously
been called on that instance, if I understand it correctly.
Line 1875: A client connects to the proxy server
Line 2190: The client does PLAY, the RTPInterface 0x36f5110 is still
referring to now closed socket 13 which causes select() to return an
error.

By the way, a read error on the TCP socket will cause
RTSPClient::handleAlternativeRequestByte to be called with requestByte
set to 0xff which allows the RTSPClient to do some cleanup.
In case of a write error detected in RTPInterface::sendDataOverTCP,
requestByte will not be set to 0xff. Is this intentional?