[Live-devel] Race condition bug fix

Geoff Cleary gcleary at sightlogix.com
Thu Sep 13 07:26:10 PDT 2007


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. 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). My patch partially
solves the problem in this case because our requests are always satisfied by
one read and using ptr will pass parseRTSPRequestString the second request.

 

Perhaps the correct protection for this lies at a higher level where we can
prevent the next request from being handled until the resetRequestBuffer is
complete?

 

Geoff

=======================

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information. Any unauthorized review, use, disclosure, or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.

  _____  

From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On 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.  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 data - as
passed to "parseRTSPRequestString()" - must be "fRequestBytesAlreadySeen",
not "bytesRead".

 

What specifically was causing you problems with the original code?  Can you
describe a specific sequence of incoming RTSP requests that was causing
problems??

-- 


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20070913/36028968/attachment.html 


More information about the live-devel mailing list