[Live-devel] Blocking socket

Jeremy Noring jnoring at logitech.com
Fri Jan 22 12:23:34 PST 2010


On Sat, Jan 16, 2010 at 9:39 PM, Ross Finlayson <finlayson at live555.com>wrote:

> Looking at the original patch, it's pretty clear that the author forgot to
>> set the socket back to be blocking.  But considering that this issue has
>> been present for well over a year, I have to wonder whether or not the
>> RTSPClient even needs to be run on a blocking socket. (Ross, you know the
>> most about this, so I'd be interested to hear your take on things).
>>
>
> I'm not planning on doing much with the existing "RTSPClient" code, because
> this code will soon be significantly overhauled so that it does I/O
> asynchronously, using the event loop, rather than the current
> blocking-with-timeout model (which doesn't fit with the event-driven model
> of the rest of the library's code).  This change will also eliminate the
> need for a "timeout" parameter (although the existing API will probably kept
> - as an option - for a while, for backwards compatibility).
>
> Fixing "RTSPClient" is high priority (second only to fixing the problems
> with RTP-over-TCP).


I've had a chance to test this change, and everything still seems to work OK
for me (I use the RTSPClient to pull directly from a Live555 on-demand
server; I also use the darwin push code, which uses the RTSPClient
internally).  How do you want the patch?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100122/6ccebd5f/attachment.html>


More information about the live-devel mailing list