[Live-devel] Server runaway streams for shared session for RTP-over-TCP client

Ross Finlayson finlayson at live555.com
Tue Aug 31 11:11:37 PDT 2010


>I am using the RTSP server functionality of the LiveMedia library, 
>and I might have resolved a client session management issue.  The 
>senario is when a ServerMediaSubsession is shared 
>[reuseFirstSource=True] and clients choose RTP-over-TCP for 
>streaming mode, only the last requested RTP-over-TCP 
>RTSPClientSession can be torn down.  All of the objects under the 
>ServerMediaSession will be runaways.  The MediaSink keeps playing, 
>and the RTPInstance writes with socket error.  The stderr shows 
>socket write attempts after all of the RTSP clients are closed.
>
>I am trying to limit the scope of the impacted code, and there seems 
>to be two area in the RTPInstance.cpp that are contributing to the 
>problem.  #1, The 
>RTPInterface::setServerRequestAlternativeByteHandler() function is 
>overwriting the handler and clientData of an already assigned 
>SocketDescriptor object.  It makes all existing socket descriptor of 
>the server media subsession to map to the latest RTSPClientSession 
>instance.  #2, When RTCPInstance::addStreamSocket() function adds a 
>new stream channel, the RTPInterface::stopNetworkReading() function 
>calls deregisterSocket() and wipes out the existing SocketDescriptor 
>to RTSPClientSession mapping.  Therefore, only the last newly added 
>SocketDescriptor has a valid fServerRequestAlternativeByteHandler to 
>notify of RTSP TEARDOWN command.

At first I didn't pay much attention to this email, both because you 
were (at first) working with an old version of the code, but also 
because you were using a "@hotmail.com" email address, which serious 
professionals do not use.  (If you want to be taken seriously on this 
mailing list, then you should not use "@hotmail", "@yahoo", 
"@gmail"-type addresses :-)

But your analysis of the problem was exactly right.  I have now 
installed a new version of the code (2010.08.31) that should, I hope, 
fix this problem.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/


More information about the live-devel mailing list