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

John Tam tamj01 at hotmail.com
Wed Sep 8 08:00:10 PDT 2010


Hello,
 
Thanks for the fix.  And I will take your advise and use a different email account when I post a new issue.  For the moment, I am running into another senario of a runaway RTP-over-TCP session, and it is preventing me from testing your last fix.  
 
The problem is in the SocketDescriptor::tcpReadHandler1() function between the lines 362-368 in RTPInterface.cpp.  What happens is that the handler could not complete to frame the TEARDOWN command before the client shuts the socket.  It results in a socket read error, and there is no provision to teardown the client session.  For whatever reason, this senario keeps happening to me nowadays although I am using the same client program [VLC 0.9.6] as before, and I cannot verify your last fix.
 
Regards,
John Tam
 
> Date: Tue, 31 Aug 2010 11:11:37 -0700
> To: live-devel at ns.live555.com
> From: finlayson at live555.com
> Subject: Re: [Live-devel] Server runaway streams for shared session for RTP-over-TCP client
> 
> >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/
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100908/14592fa0/attachment.html>


More information about the live-devel mailing list