[Live-devel] RTSP socket from a server remains open after a client disconnection

[Warren Young]

On May 30, 2018, at 7:34 AM, GENESTIER Denis <denis.genestier at thalesgroup.com> wrote:
> 
> Then if you disconnect the Ethernet wire of the computer B, the server will close the session, the RTP and RTCP sockets (in UDP mode), but not the RTSP connection (in TCP)

I’d say the real mystery here is how the UDP streams are being cut off, not why the TCP connection isn’t being dropped.

The RTSP TCP connection isn’t being dropped because that’s how TCP works, on purpose.

You might be expecting different behavior because historically[*] Windows would do media sensing and then drop all the active TCP connections on that interface if the physical media connection was lost, but I believe this went away with the widespread deployment of wifi, where temporary media loss is a frequent occurrence.

This is why TCP behaves as it does: temporary loss of the transmission medium is not a fatal error! The media-level connection may be restored before the next time it’s needed, so why drop all of the connections that were using that medium?

Linux, the BSDs, and Unix have always treated loss of the transmission medium as a temporary condition.  This is correct behavior.  Windows’ historical behavior was a serious bug, and I’m glad it doesn’t do that any more.

Before switching away from Windows on the desktop at work, I remember being forced to reestablish SSH connections from my Windows desktop to the servers I was managing on every power blip, simply because I didn’t have the nearest network switch plugged into the UPS.  Annoying!  The SSH connections were still valid; there was no reason to drop them, since they didn’t need the physical transmission medium to be up until my next keystroke on that connection.

As for your UDP streams, it’s not clear to me how medium loss is even being detected in your case.  UDP is an unreliable transmission protocol, so that in many cases, you’re never informed that a datagram was never delivered.  I can only guess that somehow it is being detected and you’re getting ICMP unreachable packets back, which is cluing Live555 into dropping those streams, but without seeing a packet capture showing it, that’s just a guess.

As Ross says, it’s legal for the RTSP stream to remain up after the UDP streams it was managing have gone away.  The client could very well request a new set of streams via the RTSP connection after the Ethernet cable is plugged back in.

If you’re reporting this non-bug out of some sense of duty only, then that’s the end of it.  It’s not a bug, so it shouldn’t be fixed.

If instead you’re reporting this because it’s causing some real problem for your system, such as resource exhaustion or tying up a TCP 4-tuple and thereby causing downstream problems, then I’d suggest setting up short-duration per-socket TCP keepalives on the RTSP socket by subclassing Live555:

    http://coryklein.com/tcp/2015/11/25/custom-configuration-of-tcp-socket-keep-alive-timeouts.html

We’ve had to do this in our software when dealing with embedded devices that can accept only one TCP connection on a given TCP port at a time, so that if the TCP connection goes stale in the way you described, the device will never accept another TCP connection again until it’s been rebooted.

> From my point of view, it is a resource leak.

The resource is still in use, and it will be cleaned up when the RTSP server restarts.


[*] I don’t remember exactly when this bogus behavior in Windows was fixed.  It was definitely occurring in Windows 2000 and XP, and it no longer occurs in Windows 7 and up, but I suspect it actually changed in Vista.