<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<style>
<!--
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.EmailStyle17
{mso-style-type:personal;
font-family:Arial;
color:navy;}
span.EmailStyle18
{mso-style-type:personal;
font-family:Arial;
color:navy;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:Arial;
color:navy;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 77.95pt 1.0in 77.95pt;}
div.Section1
{page:Section1;}
-->
</style>
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>Hi Ross,<o:p></o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>I thought I should open a new thread for the RTSPOverTCP lockout issue
that I’ve come across (from my response to Jeremy’s message (subject:
Detecting network failure)).<o:p></o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>I apologize for the detail here…if you have any suggestions/preferences
for further communications, please advise.<o:p></o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>In case it helps, I've reproduced the CPU spike with RTPoverRTSP (as
well as RTSPOverHTTP)...so, I'm fairly convinced it wasn’t anything I've
added for RTSPOverHTTP.<o:p></o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>My test case is to simply open a VLC RTPoverRTSP client session, and
immediately close it...<o:p></o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>The only reason I added the return of the send() status was to allow recovery
from (avoidance of) whatever cpu bound processing loop which may have been causing
the cpu utilization spike (lockout).<o:p></o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>Anyway, I was pursuing the thought that it might have had to do with
the special handling for RTPOverTCP streams in sendRTPOverTCP and/or the tcpReadHandler()
upon connection reset by peer.<o:p></o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>A side question/concern, is that readSocket (and readSocketExact) always
use recvfrom, even though, in this case, we are reading from stream sockets...therefore,
the CONNECTION state will never be considered by the socket layer. If we used
recv() we might get a "connection reset by peer" indication....no?
The problem I had when I tried that theory out, is that select() always returns
timeout so we never get to the recv() or recvfrom() calls…<o:p></o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>The lockup doesn't occur every time...<o:p></o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>When it doesn’t lockup, readSocket() returns with result = -1,
and errno indicates the 104 (Connection reset by peer)…and therefore the
background readhandler gets turned off..<o:p></o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>When it does lockup, I do NOT get that same indication…<o:p></o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>so, I'm suspicious that temporary lockout is a result of some race
condition in the timing of receiving the (VLC) peer TCP disconnect and where we
are in the processing of the "interleaved message(s)"...<o:p></o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>VLC sends the TEARDOWN (which we don't "see" because once we
start the tcpReadHandler we are then *only* looking for RTCP messages, NOT any further
RTSP messages like TEARDOWN or SET_PARAMETER (e.g. for keepalive...true??),
sometimes (why only sometimes?) followed by the RTCP BYE, then it immediately (~100us
later) closes the TCP connection.<o:p></o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>I think there may be a race there that causes some grief in the
tcpReadHandler() processing...where, depending on where we're at in our
interleaved packet handling when the TCP connection gets reset by the peer, we
end up in a non-blocking, and non-exiting near infinite loop...<o:p></o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>Regarding the TEARDOWN, it would seem we might need a more stateful
implementation of the interleaved stream parsing, no? Or, is it by design that
we no longer process the TEARDOWN, because we SHOULD see the RTCP BYE, or will
otherwise timeout the connection??<o:p></o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>I think the problem case is where we are waiting for the next
'$'...where we call readSocket() with a non-NULL timeout (all other calls to
readsocket() (for the remaining portions of the exchange) use a NULL timeout so
the select call will block…<o:p></o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>FWIW, In my testing, disconnecting the network doesn't cause the CPU
spike...like the quick STOP of VLC did when I was testing RTSPOverHTTP...<o:p></o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>As I mentioned in my response to Jeremy, the client session will
eventually be brought down via liveness check "due to inactivity"...however,
my linux system gets pretty locked up until that expiry triggers...<o:p></o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>I appreciate any light you may be able to shine on this one.<o:p></o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p> </o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'>Randy<o:p></o:p></span></font></p>
<p class=MsoPlainText><font size=2 face="Courier New"><span style='font-size:
10.0pt'><o:p> </o:p></span></font></p>
</div>
</body>
</html>