> Explanation. > - When RTSPServer::RTSPClientSession is created livenessTimeoutTask() is > scheduled and it gets rescheduled while connection is on. > - 60 seconds after connection is closed livenessTimeoutTask() is executed. It > will delete clientSession, which will call reclaimStreamStates(), which > deletes stream. Eventually RTPInterface::removeStreamSocket() gets called > with file descriptor from connection #2 > - At that time this file descriptor belongs to connection #3
Right now I don’t see how this can be happening, because the only way connection #3 could be using the same socket number as connection #2 would be if that socket were previously closed - and I don’t see how the socket can be closed while an existing “RTSPClientConnection” has it. > I assume that it is not expected that RTSPClientSession outlives > RTSPClientConnection No, you assume incorrectly :-) A ‘client session’ and a ‘client connection’ are independent. The RTSP specification allows a single ‘client session’ to use multiple TCP connections (e.g., to use a separate TCP connection for each RTSP command that it sends), and it also allows a single TCP connection to be used for more than one RTSP ‘client session’ (either sequentially, or concurrently). Admittedly, both of these things are uncommon, but they are permitted, which is why we make “RTSPClientConnection”s and “RTSPClientSession”s independent. As always, I assume that you’re using a recent version of the code. (Several bugs related to RTP/RTCP-over-TCP streaming were fixed in recent years.) Ross Finlayson Live Networks, Inc. http://www.live555.com/
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
