>when two DESCRIBE requests are pipelined,
But that's not what you showed in the trace that you included in your
earlier message. That trace showed DESCRIBE, SETUP, PLAY, DESCRIBE,
SETUP, PLAY - all handled correctly - with only a trailing TEARDOWN
not handled correctly (because the URL was ba
See embedded comment below.
Geoff
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:live-devel-
> [EMAIL PROTECTED] On Behalf Of Ross Finlayson
> Sent: Friday, September 14, 2007 10:49 AM
> To: LIVE555 Streaming Media - development & use
> Subject: Re: [Live
First, there is non't really a "race condition" going on here,
because our server code is single-threaded.
Also, you are using an old version of the "LIVE555 Streaming Media"
code. You will need to upgrade to the latest version of the code.
(No support is given for old versions of the code.)
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. There
Behalf Of Ross Finlayson
Sent: Wednesday, September 12, 2007 9:01 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Race condition bug fix
The following fix prevents a bug when two requests are processed in close
proximity.
No, the original code was correct.
The following fix prevents a bug when two requests are processed in
close proximity.
No, the original code was correct. It's possible that an incoming
RTSP request will require more than one socket read in order to
obtain all the data for the request. In that case, the length of the
request
