[Live-devel] Really blocking?

Němec Alexandr a.nemec at atlas.cz
Thu Feb 11 00:08:57 PST 2010


An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100211/211810cc/attachment.html>
-------------- next part --------------
So was I.
I also made the RTSP server unavailable by disconnecting the cable from the *server*, so the client's network interface was running ok. Moreover, I also made my tests on Windows, so I think test conditions are the same. I now made 20 trials of disconnecting the server from the network but I was not able to reproduce the deadlock. But I think, however, that it can eventually happen (according to what I see in the code). How did you finally solve this problem? Just adding by adding a timeout or are further code changes necessary? We would also like to handle this, because this deadlock might be dangerous for our application.
Best regards
Alex
2010/2/10 Němec Alexandr <a.nemec at atlas.cz>
Hi all,
some days ago somebody (Jeremy Noring?) posted the following issue regarding RTSPClient. When using TCP transmission (-t option in openRTSP) then the client can deadlock when the network goes down. This sounds like a big problem because the client generraly should not deadlock on network problems. I tried to reproduce this behaviour, but with no luck. I used openRTSP code for my quick tests, used the -t option and I started some streams from RTSP servers. Then I destroyed the connection several times (cable disconnect etc.) but I was able to finalize the event loop safely with the watch variable with no deadlocks at all. Could anybody (maybe the original poster) put some light on this issue (how to reproduce etc.) ?
I was actually pulling the plug on the RTSP Server, so my network was still good but the server "went away," but I'd expect you could reproduce it simply by unplugging your network cable (?). Also, I'm using the RTSP client on Windows, if that makes any difference. That said, I'd only reproduce the hang if the code is in a few areas (any of the select() statements with no timeouts), so it does not reproduce 100% of the time (my guess is maybe one attempt in ten?).
I would be interested in whether or not you can reproduce this bug--it's definitely not something that is easy to reproduce, but I'm absolutely positive that I've seen it (multiple times, and in several different select() calls).


More information about the live-devel mailing list