2010/2/11 Němec Alexandr <span dir="ltr">&lt;<a href="mailto:a.nemec@atlas.cz">a.nemec@atlas.cz</a>&gt;</span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
So was I.<br>
I also made the RTSP server unavailable by disconnecting the cable from the *server*, so the client&#39;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.<br>
</blockquote><div><br>Yes, I just added a timeout everywhere readSocket* (both variants of the function) gets called.  I used 2 seconds; it is not clear to me if this is a safe change or not.<br><br>I&#39;m also wondering if my other recent patch to set the socket _back_ to blocking if a timeout to the RTSPClient is given can effect this bug; what version of Live555 are you testing with? <br>
</div></div><br>