On May 30, 2018, at 8:28 PM, Ross Finlayson <finlay...@live555.com> wrote: > >> On May 30, 2018, at 7:16 PM, Warren Young <war...@etr-usa.com> wrote: >> >> On May 30, 2018, at 7:34 AM, GENESTIER Denis >> <denis.genest...@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. > > No, this isn’t a mystery at all. The reason the UDP streams are being ‘cut > off’ is because the server is closing/deleting the RTSP ‘session' (not > ‘connection’) - which it does automatically after a certain period of > inactivity (the parameter “reclamationTestSeconds”; by default, 65 seconds).
So there is a protocol-level keepalive in there. I probably knew that once. :) > If there’s a mystery, it’s why the *client* is apparently becoming inactive, > but still keeping the TCP socket alive. Denis told us: the client computer’s Ethernet cable is being unplugged, so even if you kill the software client, no RST/FIN can go out. If the cable is left unplugged until all of the retries for that packet expire, the server will forever be under the impression that the connection is still alive. Thus my recommendation to enable TCP keepalives. That will detect the remote peer’s loss of access to the Ethernet media, causing Live555 to get 0 or -1 back from a recv() call, depending on how Live555’s I/O loop works. _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
