<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div><div><font face="Calibri" size="3">We use the event loop ‘watch variable’ mechanism to stop the event loop and
terminate our application (which is based on the testRTSPClient sample).
This works about 99.9% of the time. However our systems run 24/7 and
occasionally we are finding that the event loop does not terminate. After
some painful investigation we figured out why. The problem is in
RTPInterface.cpp, member function sendDataOverTCP(). The event loop is
hung in the socket send function – because the socket is in blocking mode.</font></div></div></div></div></blockquote><div><br></div>Note that the blocking "send()" is done *only if* the immediately-previous, non-blocking "send()" succeeded in writing only part of the data. That's why it's done. And it has to be done (and therefore, your timeout hack couldn't be applied, unless - at the end of the timeout - the socket were always closed). See</div><div><span class="Apple-tab-span" style="white-space:pre"> </span><a href="http://lists.live555.com/pipermail/live-devel/2014-April/018270.html">http://lists.live555.com/pipermail/live-devel/2014-April/018270.html</a></div><div><br></div><div>I don't know why this "send()" is blocking for a long period of time for you, but it suggests that you may have severe network congestion (and insufficient network bandwidth), for which RTP/RTCP-over-TCP delivery is not appropriate. As noted in the link above, you can now disable RTP/RTCP-over-TCP delivery in your server.</div><div><br></div><div><br></div><div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div><div style="font-family: Calibri; font-size: 12pt;">Another option would be to close the socket handle from a different thread
which would cause the socket send function to return. (This is how we
break out of a blocking socket call in other environments). However there
does not seem to be a way to get the socket handle since these variables are
private</div></div></div></div></blockquote><div><br></div>No, they're not. They're "protected". Note the fields "fClientInputSocket" and "fClientOutputSocket" in "RTSPServer::RTSPClientConnection". You could subclass "RTSPServer::RTSPClientConnection" (and therefore also subclass "RTSPServer" and reimplement "createNewClientConnection()"). Then your subclass would have access to these two sockets (which are usually the same, unless you're doing RTSP/RTP/RTCP-over-HTTP).</div><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">Ross Finlayson<br>Live Networks, Inc.<br><a href="http://www.live555.com/">http://www.live555.com/</a></span></span>
</div>
<br></body></html>