<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
Strange indeed. This unable to frame the TEARDOWN message has not been happening before, otherwise, I would not be able to track down the original reported problem. I guess having to read one byte at a time, going back to the outer loop and doing a select() can open a big window of opportunity for things to happen.<BR>
<BR>
I ran it again with VLC 1.1.3. I am attaching the console debug messages and Wireshark network capture. In this instance, the tcpReadHandler1() code began to read the 'T' then turned off reading of socket and left the TCP session dangling. The network capture shows the whole TEARDOWN message being sent by the client, and the client even sent a RTCP BYE before closing the connection.<BR>
<BR>
I think in general, the tcpReadHandler1() should initiate some cleanup upon a TCP socket failure because it knows the association between the socket number and the client session object. I just cannot come up iwth a good suggestion to tie it together to the fServerRequestAlternativeByteHandler callback.<BR>
<BR>
[repeat .....]<BR>sendRTPOverTCP: 1448 bytes over channel 0 (socket 4172)<BR>sendRTPOverTCP: completed<BR>sendRTPOverTCP: 1448 bytes over channel 0 (socket 4172)<BR>sendRTPOverTCP: completed<BR>sendRTPOverTCP: 1448 bytes over channel 0 (socket 4172)<BR>sendRTPOverTCP: completed<BR>sendRTPOverTCP: 762 bytes over channel 0 (socket 4172)<BR>sendRTPOverTCP: completed<BR>sendRTPOverTCP: 1448 bytes over channel 0 (socket 4172)<BR>sendRTPOverTCP: completed<BR>RTSPClientSession[03A1D018]::handleRequestBytes() read 1 new bytes:T<BR>sendRTPOverTCP: 1448 bytes over channel 0 (socket 4172)<BR>sendRTPOverTCP: failed!<BR>sendRTPOverTCP: 1448 bytes over channel 0 (socket 4172)<BR>sendRTPOverTCP: failed!<BR>sendRTPOverTCP: 1448 bytes over channel 0 (socket 4172)<BR>sendRTPOverTCP: failed!<BR>sendRTPOverTCP: 1448 bytes over channel 0 (socket 4172)<BR>sendRTPOverTCP: failed!<BR>sendRTPOverTCP: 1448 bytes over channel 0 (socket 4172)<BR>sendRTPOverTCP: failed!<BR> [repeat .....]<BR><BR>
Regards,<BR>
John Tam<BR>
<BR>
<HR id=stopSpelling>
Date: Wed, 8 Sep 2010 18:47:49 -0700<BR>To: live-devel@ns.live555.com<BR>From: finlayson@live555.com<BR>Subject: Re: [Live-devel] Server runaway streams for shared session for RTP-over-TCP client<BR><BR>
<META content="Microsoft SafeHTML" name=Generator>
<STYLE>
.ExternalClass blockquote, .ExternalClass dl, .ExternalClass ul, .ExternalClass ol, .ExternalClass li
{padding-top:0;padding-bottom:0;}
</STYLE>
<BLOCKQUOTE>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. <BR> <BR>The problem is in the<FONT size=-1> SocketDescriptor::tcpReadHandler1() function between the lines 362-368 in</FONT> 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.</BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>Thanks for the report. Unfortunately I can't reproduce this myself, so you're going to have to help track this down a little more.</DIV>
<DIV><BR></DIV>
<DIV>It's strange that you're getting a socket read error before the server has read, parsed and processed the incoming "TEARDOWN" request. What is supposed to be happening is that "RTSPServer:: handleRequestBytes(1)" gets called - one byte at a time - for each byte in the incoming "TEARDOWN" request. When it sees the last byte of the request (the final LF in the CR-LF-CR-LF sequence), it should then be calling "handleCmd_withinSession("TEARDOWN", ...)", which should then in turn call "handleCmd_TEARDOWN()" to close the session. It is only the *next* (single-byte) socket read that should be getting a read error.</DIV>
<DIV><BR></DIV>
<DIV>Could you look into why this is not working properly for you?</DIV>
<DIV><BR></DIV>
<DIV><BR></DIV>
<BLOCKQUOTE> 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.</BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>Does the problem still occur if you use a new version of VLC (1.1.3)? It shouldn't make a difference, but it's worth checking...</DIV><PRE>--
</PRE>
<DIV><BR>Ross Finlayson<BR>Live Networks, Inc.<BR>http://www.live555.com/</DIV><BR>_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel </body>
</html>