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
should improve the performance of both client and server applications.
On a related note, here's one other hack I had to add to prevent crashing:
void
RTSPServer::RTSPClientSession::handleAlternativeRequestByte1(u_int8_t
requestByte) {
// Add this character to our buffer; then try to handle the data
that we have buffered so far:
if (fRequestBufferBytesLeft == 0) return;
if (fRequestBytesAlreadySeen >= RTSP_BUFFER_SIZE ) return; //
hack: don't let us overflow fRequestBuffer, and there's some bug
//
with sessions containing multiple subsessions, when streaming over
//
TCP that causes this to fail miserably.
fRequestBuffer[fRequestBytesAlreadySeen] = requestByte;
handleRequestBytes(1);
}
...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.
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.
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
