[Live-devel] Race condition bug fix

[Geoff Cleary]

Ross

I have found out more about what the client (Genetec V4.0) is doing.
It is trying to pipeline requests for two Unicast streams. It expects
the two streams to play concurrently, however the server assigns the
same session IDs. What do you think standard behavior should be in
this regard? I have attached a trace from Wireshark.

The race condition occurs when two pipelined requests come in.

Thanks for your help, Geoff


-------------- next part --------------
>I agree that in the case of two reads to build a request, my code
>does not pass the correct length, however there is still a problem.
>Sorry I did not explain it fully in my original mail.
>
>In our use of the server, the client often makes two requests for a
>pair of streams from the server. Therefore two requests arrive very
>closely in time. The second starts processing after the first is
>read but before resetRequestBuffer() resets the
>fRequestBytesAlreadySeen.

That's because the first request must not have ended correctly -
i.e., with <cr><lf><cr><lf>

>  So the second request is added to the end of the first in the
>fRequestBuffer and parseRTSPRequestString is called with a pointer
>to the beginning of the buffer (which now has both requests, first
>then second).

Ditto.  I suspect that the first request is not well-formed, so the
server is not recognizing when it's ending.

Mostl likely this is because it doesn't end with  <cr><lf><cr><lf>.
What is your RTSP client?  (If your RTSP client used our software,
then you wouldn't have this problem :-)
--

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
-------------- next part --------------
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Pipelined.txt
Url: http://lists.live555.com/pipermail/live-devel/attachments/20070914/63819432/attachment.txt