[Live-devel] Tricky bug in RTSP-on-HTTP server implementation?

[Cristiano Belloni]

  Dear Ross,
I noted a very strange behaviour with you latest liveMedia implementation.
On my workstation (Linux OS), it works like a charm. On other systems 
(with Linux OS as well), it seems not to respond to the OPTIONS post, 
time-outing every client (except openRTSP, that after ~ 30 seconds tries 
a DESCRIBE - and succeeds). Please note the test program I use and the 
library version - the 20 Oct one is the same across all these systems.

After a session of debugging and wireshark, turns out that in the 
systems where liveMedia *does* not respond to the OPTIONS post, the 
first incomingRequestHandler1 sucks from the net the actual POST request 
and its headers *plus* the first Base64-Encoded request (that is the 
RTSP OPTIONS one). It can happen, because in TCP there is no assumption 
that the number of the write()s at one end is equal to the number of the 
read()s on the other end.
Having the two in one single buffer, it seems that liveMedia parses the 
first and ignores the second. The result? It does not respond to the 
OPTIONS while the client is waiting and the client eventually times out.

Just to be clear, here are the DEBUG headers (I added some fprintf here 
and there):

Returned from incomingRequestHandler1()
accept()ed connection from 192.168.1.9710This is the 
incomingRequestHandler1 calling readSocket with = 0 and 
fRequestBufferBytesLeft = 10000
readSocket returned with bytesRead = 431, now calling handleRequestBytes
RTSPClientSession[0x888d8]::handleRequestBytes() read 431 new bytes:POST 
/video HTTP/1.0
User-Agent: openRTSP (LIVE555 Streaming Media v2010.04.09)
x-sessioncookie: 0a8998e09cb7d658f9712c2
Content-Type: application/x-rtsp-tunnelled
Pragma: no-cache
Cache-Control: no-cache
Content-Length: 32767
Expires: Sun, 9 Jan 1972 00:00:00 GMT

T1BUSU9OUyBydHNwOi8vMTkyLjE2OC4xLjIyMC92aWRlbyBSVFNQLzEuMA0KQ1NlcTogMQ0KVXNlci1BZ2VudDogb3BlblJUU1AgKExJVkU1NTUgU3RyZWFtaW5nIE1lZGlhIHYyMDEwLjA0LjA5KQ0KDQo=
parseRTSPRequestString() failed
parseHTTPRequestString() succeeded, returning cmdName "POST", 
sessionCookie "0a8998e09cb7d658f9712c2"
Handled HTTP "POST" request (client input socket: 6)
Returned from incomingRequestHandler1()

As you can see, the first readSocket returned with bytesRead = 431. 
Looking at it in Wireshark, it is composed by two packets, one long 275 
bytes (that contains the POST etc.) and one 156, which contains the 
Base64 OPTIONS request. The latter gets ignored.

This is what the same logs look like in a system that does the "correct" 
thing:

Returned from incomingRequestHandler1()
accept()ed connection from 192.168.1.9710This is the 
incomingRequestHandler1 calling readSocket with = 0 and 
fRequestBufferBytesLeft = 10000
readSocket returned with bytesRead = 275, now calling handleRequestBytes
RTSPClientSession[0x93058d8]::handleRequestBytes() read 275 new 
bytes:POST /video HTTP/1.0
User-Agent: openRTSP (LIVE555 Streaming Media v2010.04.09)
x-sessioncookie: 42d4916a5815383b8142f83
Content-Type: application/x-rtsp-tunnelled
Pragma: no-cache
Cache-Control: no-cache
Content-Length: 32767
Expires: Sun, 9 Jan 1972 00:00:00 GMT

(first packet)

parseRTSPRequestString() failed
parseHTTPRequestString() succeeded, returning cmdName "POST", 
sessionCookie "42d4916a5815383b8142f83"
Handled HTTP "POST" request (client input socket: 6)
Returned from incomingRequestHandler1()
This is the incomingRequestHandler1 calling readSocket with = 0 and 
fRequestBufferBytesLeft = 10000
readSocket returned with bytesRead = 156, now calling handleRequestBytes
RTSPClientSession[0x9300990]::handleRequestBytes() read 156 new 
bytes:T1BUSU9OUyBydHNwOi8vMTkyLjE2OC4xLjk3L3ZpZGVvIFJUU1AvMS4wDQpDU2VxOiAxDQpVc2VyLUFnZW50OiBvcGVuUlRTUCAoTElWRTU1NSBTdHJlYW1pbmcgTWVkaWEgdjIwMTAuMDQuMDkpDQoNCg==
Base64-decided 156 input bytes into 115 new bytes:OPTIONS 
rtsp://192.168.1.97/video RTSP/1.0
CSeq: 1
User-Agent: openRTSP (LIVE555 Streaming Media v2010.04.09)

(second packet, *not* ignored this time).

The problem is found randomly in the systems. Probably it depends on the 
net stack, networking hardware and/or network load and lag.
Can you confirm me it's a bug?

Best Regards,
Cristiano.

-- 
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
belloni at imavis.com <mailto://belloni@imavis.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101022/e55a533d/attachment.html>