<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: [Live-devel] Server runaway streams for shared
session</title></head><body>
<blockquote type="cite" cite>Thanks for the fix.&nbsp; And I will take
your advise and use a different email account when I post a new
issue.&nbsp; For&nbsp;the moment, I am running into another senario
of&nbsp;a runaway RTP-over-TCP session,&nbsp;and it is preventing me
from&nbsp;testing your last fix.&nbsp;&nbsp;<br>
&nbsp;<br>
The problem is in&nbsp;the<font size="-1">
SocketDescriptor::tcpReadHandler1() function&nbsp;between
the&nbsp;lines 362-368&nbsp;in</font> RTPInterface.cpp.&nbsp; What
happens is that the handler could not complete to frame the TEARDOWN
command before the client shuts the socket.&nbsp; It results in a
socket read error, and there is
no&nbsp;provision&nbsp;to&nbsp;teardown the client
session.</blockquote>
<div><br></div>
<div>Thanks for the report.&nbsp; 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 &quot;TEARDOWN&quot;
request.&nbsp; What is supposed to be happening is that
&quot;RTSPServer:: handleRequestBytes(1)&quot; gets called - one byte
at a time - for each byte in the incoming &quot;TEARDOWN&quot;
request.&nbsp; When it sees the last byte of the request (the final LF
in the CR-LF-CR-LF sequence), it should then be calling
&quot;handleCmd_withinSession(&quot;TEARDOWN&quot;, ...)&quot;, which
should then in turn call &quot;handleCmd_TEARDOWN()&quot; to close the
session.&nbsp; 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 type="cite" cite>&nbsp;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)?&nbsp; It shouldn't make a difference, but it's worth
checking...</div>
<x-sigsep><pre>-- 
</pre></x-sigsep>
<div><br>
Ross Finlayson<br>
Live Networks, Inc.<br>
http://www.live555.com/</div>
</body>
</html>