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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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/
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
