On Tue, Jun 15, 2010 at 2:55 AM, Ross Finlayson <span dir="ltr"><<a href="mailto:finlayson@live555.com">finlayson@live555.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I've now installed a new version (2010.06.15) of the code that completely removes the "blockUntilReadable()" function. This means that "readSocket()" no longer calls "select()", which<br>
should improve the performance of both client and server applications.<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On a related note, here's one other hack I had to add to prevent crashing:<br>
<br>
void RTSPServer::RTSPClientSession::handleAlternativeRequestByte1(u_int8_t requestByte) {<br>
// Add this character to our buffer; then try to handle the data that we have buffered so far:<br>
if (fRequestBufferBytesLeft == 0) return;<br>
if (fRequestBytesAlreadySeen >= RTSP_BUFFER_SIZE ) return; // hack: don't let us overflow fRequestBuffer, and there's some bug<br>
// with sessions containing multiple subsessions, when streaming over<br>
// TCP that causes this to fail miserably.<br>
fRequestBuffer[fRequestBytesAlreadySeen] = requestByte;<br>
handleRequestBytes(1);<br>
}<br>
<br>
<br>
...I previously reported this. When there are multiple sessions being streamed that contain both audio and video (i.e. multiple subsessions) over TCP, sometimes the server will crash with an access violation by walking off the end of fRequestBuffer. I do not understand the crash; I do know that this code prevents it.<br>
</blockquote>
<br></div>
I don't understand why the "hack" line should be necessary, because "handleRequestBytes()" should already be testing for buffer overflow. However, this newest release of the code improves the handling of RTP/RTCP/RTSP-over-TCP, so I'm hoping that it happened to fix the bug as well.</blockquote>
<div><br>It fails on this line in handleAlternativeRequestByte1:<br><br>fRequestBuffer[fRequestBytesAlreadySeen] = requestByte;<div> </div>...so no, it does not test for buffer overflow. For whatever reason, fRequestBuffer gets set to a very large number (i.e. greater than 10K), which causes this function to crash with an access violation. It doesn't have anything to do with handleRequestBytes().<br>
<br></div></div><br>