Mark, There are two huge problems with this. First, “ClientSession::livenessTimeoutTask()” is usually called when a client happens to go away without sending a RTSP “TEARDOWN” command. But other clients might continue to be (concurrently) accessing the server (in this case, a proxy server) OK. Terminating all current client connections (and thus, all pending RTSP commands on those client connections) just because one client has timed out would be wrong.
But more generally, this ignores the distinction between “ClientSession”s and “ClientConnection”s. Our server implementation treats these as independent objects. The reason for this is that it is possible for a single ‘client session’ to use more than one ‘client connection’ (i.e., TCP socket) - e.g., a client could use a separate TCP connection to send each RTSP command. And it is also possible (even though our own RTSP client implementation doesn’t support this) for a client to use a single ‘client connection’ (i.e., TCP socket) to send commands for more than one ‘client session’ (either sequentially or concurrently). Thus, our server implementation treats “ClientSession”s and “ClientConnection”s (i.e., TCP sockets) independently. “ClientSession::livenessTimeoutTask()” is used to reclaim “ClientSession” objects, *not* “ClientConnection” objects. “ClientConnection” objects are reclaimed by the “RTSPServer::handleRequestBytes()” function, if the “newBytesRead” parameter - i.e., the value returned by calling “recvfrom()” on the TCP socket (after the socket is handled by the server’s event loop) - is <0. So, in your case, for some reason, "ClientConnection”s (i.e., TCP sockets for incoming ‘front-end’ clients) are not getting reclaimed in your proxy server as clients go away. Which means that, for some reason, these TCP sockets are not getting handled by the event loop, and/or, for some reason, calling “recvfrom()” on these sockets is not returning a value <0. You’re going to have to figure out why this is happening, but I suspect it has something to with the fact that you’re running the code on Windows (again, for some reason :-). But note that these sockets are handling connections from incoming (front-end) clients; they have nothing to do with the proxy’s (back-end) connection to the media source. So I don’t know why you are trying to trigger this issue by dropping packets between the media source and the proxy; that’s irrelevant here. 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
