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

[Ross Finlayson]

>> I have now installed a new version (2017.01.26) of the “LIVE555 Streaming
>> Media” code that incorporates your patch (mostly).
> Thanks a lot Ross, this is great!
> 
> I've found one more more similar issue, the new one is triggered by the
> following sequence:
> - Connection to back-end server is torn down
> - The torn down connection triggers a read error which causes the socket to
>  be closed
> - If a client to the proxy at this point issues PLAY, the closed socket will
>  still be referenced, causing this error:
>  BasicTaskScheduler::SingleStep(): select() fails: Bad file descriptor

This error is always caused by a socket being closed without
	disableBackgroundHandling()
or, equivalently
	turnOffBackgroundReadHandling()
having been first called on it.  In other words, whenever a socket is being read from asynchronously (i.e., from the event loop), "disableBackgroundHandling()” or "turnOffBackgroundReadHandling()” MUST be called on the socket before it gets closed.
So, the questions are:
	1/ Which socket is being closed, and where, and
	2/ Why was "disableBackgroundHandling()” or "turnOffBackgroundReadHandling()” not called on it beforehand?

There several places in the code where  "disableBackgroundHandling()” or "turnOffBackgroundReadHandling()”  are currently called, prior to a socket being closed; in particular:
	- For a RTP/RTCP-over-RTSP socket, “turnOffBackgroundReadHandling()” is called in the “SocketDescriptor” destructor (“RTPInterface.cpp”).
	- For a “RTSPClient", "disableBackgroundHandling()” is called in “resetTCPSockets()” (“RTPInterface.cpp”).
	- For a "RTSPServer::RTSPClientConnection”, “disableBackgroundHandling()” is called when the client connection is closed (“RTSPServer.cpp”, line 578)

So, which one did we miss?


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