> 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? _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
