<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-15">
</head>
<body text="#000000" bgcolor="#ffffff">
Dear Ross,<br>
I noted a very strange behaviour with you latest liveMedia
implementation.<br>
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.<br>
<br>
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.<br>
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.<br>
<br>
Just to be clear, here are the DEBUG headers (I added some fprintf
here and there):<br>
<br>
Returned from incomingRequestHandler1()<br>
accept()ed connection from 192.168.1.9710This is the
incomingRequestHandler1 calling readSocket with = 0 and
fRequestBufferBytesLeft = 10000<br>
readSocket returned with bytesRead = 431, now calling
handleRequestBytes<br>
RTSPClientSession[0x888d8]::handleRequestBytes() read 431 new
bytes:POST /video HTTP/1.0<br>
User-Agent: openRTSP (LIVE555 Streaming Media v2010.04.09)<br>
x-sessioncookie: 0a8998e09cb7d658f9712c2<br>
Content-Type: application/x-rtsp-tunnelled<br>
Pragma: no-cache<br>
Cache-Control: no-cache<br>
Content-Length: 32767<br>
Expires: Sun, 9 Jan 1972 00:00:00 GMT<br>
<br>
T1BUSU9OUyBydHNwOi8vMTkyLjE2OC4xLjIyMC92aWRlbyBSVFNQLzEuMA0KQ1NlcTogMQ0KVXNlci1BZ2VudDogb3BlblJUU1AgKExJVkU1NTUgU3RyZWFtaW5nIE1lZGlhIHYyMDEwLjA0LjA5KQ0KDQo=<br>
parseRTSPRequestString() failed<br>
parseHTTPRequestString() succeeded, returning cmdName "POST",
sessionCookie "0a8998e09cb7d658f9712c2"<br>
Handled HTTP "POST" request (client input socket: 6)<br>
Returned from incomingRequestHandler1()<br>
<br>
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.<br>
<br>
This is what the same logs look like in a system that does the
"correct" thing:<br>
<br>
Returned from incomingRequestHandler1()<br>
accept()ed connection from 192.168.1.9710This is the
incomingRequestHandler1 calling readSocket with = 0 and
fRequestBufferBytesLeft = 10000<br>
readSocket returned with bytesRead = 275, now calling
handleRequestBytes<br>
RTSPClientSession[0x93058d8]::handleRequestBytes() read 275 new
bytes:POST /video HTTP/1.0<br>
User-Agent: openRTSP (LIVE555 Streaming Media v2010.04.09)<br>
x-sessioncookie: 42d4916a5815383b8142f83<br>
Content-Type: application/x-rtsp-tunnelled<br>
Pragma: no-cache<br>
Cache-Control: no-cache<br>
Content-Length: 32767<br>
Expires: Sun, 9 Jan 1972 00:00:00 GMT<br>
<br>
(first packet)<br>
<br>
parseRTSPRequestString() failed<br>
parseHTTPRequestString() succeeded, returning cmdName "POST",
sessionCookie "42d4916a5815383b8142f83"<br>
Handled HTTP "POST" request (client input socket: 6)<br>
Returned from incomingRequestHandler1()<br>
This is the incomingRequestHandler1 calling readSocket with = 0 and
fRequestBufferBytesLeft = 10000<br>
readSocket returned with bytesRead = 156, now calling
handleRequestBytes<br>
RTSPClientSession[0x9300990]::handleRequestBytes() read 156 new
bytes:T1BUSU9OUyBydHNwOi8vMTkyLjE2OC4xLjk3L3ZpZGVvIFJUU1AvMS4wDQpDU2VxOiAxDQpVc2VyLUFnZW50OiBvcGVuUlRTUCAoTElWRTU1NSBTdHJlYW1pbmcgTWVkaWEgdjIwMTAuMDQuMDkpDQoNCg==<br>
Base64-decided 156 input bytes into 115 new bytes:OPTIONS
<a class="moz-txt-link-freetext" href="rtsp://192.168.1.97/video">rtsp://192.168.1.97/video</a> RTSP/1.0<br>
CSeq: 1<br>
User-Agent: openRTSP (LIVE555 Streaming Media v2010.04.09)<br>
<br>
(second packet, *not* ignored this time).<br>
<br>
The problem is found randomly in the systems. Probably it depends on
the net stack, networking hardware and/or network load and lag.<br>
Can you confirm me it's a bug?<br>
<br>
Best Regards,<br>
Cristiano.<br>
<br>
<div class="moz-signature">-- <br>
Belloni Cristiano<br>
Imavis Srl.<br>
<a href="http://www.imavis.com">www.imavis.com</a><br>
<a href="mailto://belloni@imavis.com">belloni@imavis.com</a><br>
</div>
</body>
</html>