Thanks for the quick answer.
If the RTP-over-TCP data is well-formed, then there shouldn't be any
blocking, because the data should be present in the correct format:
'$';1-byte stream channel id; 2-byte packet size; packet data. Perhaps
the data that you are sending is not well-formed (though it you're
using our server, it should be)?
We are using the livemedia client as well. The message is probably split
when this happens: first a command that will be ignored followed by a
report. But only the $ of the report is in the packet and the rest in a
second part. Not sure if this is possible. It might be possible that we
are doing something wrong, but the server should be robust enough to
handle any data.
You're correct, though, that the code should probably be made more
tolerant of malformed data (e.g., by including the (otherwise
optional) "timeout" parameter to "readSocket()" and "readSocketExact()").
Ok, so I'll keep the timeouts.
There are other calls to readSocket() without a timeout as well. Not
sure if these have to have the timeout? Maybe not cause it looks like
there won't be any other data before those.
Thanks again.
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
