On May 30, 2018, at 7:34 AM, GENESTIER Denis <[email protected]>
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.
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
