[Live-devel] About long time wait when server isn't available

Sean yunjnz at yahoo.com
Wed Jan 24 17:40:52 PST 2007


--- xcsmith at rockwellcollins.com wrote:

> 
> >is it OK for the RTSPClient work under non-blocking
> mode?
> This would be nice to do, but would be a non-trivial
> change to the
> code.  It might get done someday, but probably not
> soon.
> 
> I have added this to my copy the code, but I have a
> lot of paperwork to do
> before I can post my code.
> 
> Create a new protected member "struct timeval*
> fResponseTimeout" and
> initialize it to NULL in the constructor.
> Create an accessor function for setting the value of
> fResponseTimeout.
>  Then in function RTSPClient::getResponse1(), just
> inside the first "while"
> loop, change the readSocket call to:
> "readSocket(envir(), fInputSocketNum, &firstByte, 1,
> fromAddress,
> fResponseTimeout)"
> 
> The client will default to passing NULL into the
> readSocket call, so it
> will work exactly as the original client if you do
> not set the value of
> fResponseTimeout.  I have been using this
> modification in my code for a
> couple months now, and so far it works great.  If
> the server is not
> available, the calls to getResponse1() fail, and the
> RTSPClient exits the
> function with "false" return value.
> 
> Please make a post for me if you see any cases in
> which this would not
> work.
> Thank you!

Appreciate for your help on the issue,
But as my investigation, the client will block in the
function call "connect" in openConnectionFromURL,
Do we need to modify the last parameter of
setupStreamSocket from "False" to "True" for
non-blocking mode?
and it seems that the "connect" call will immediately
return with error EINPROGRESS,
in my opinion, we should check if the errno is
EINPROGRESS and then continue, isn't it?
and in that case, later the RTSPClient will send
request to the server,
should we wait for the signal of successfully
connected?
if so, how to get the signal?

Anyway, it works better than blocking if the server
isn't available according to your suggestion.
That's good.

Thanks.
Sean

> 
> Xochitl
> 
> P.S.  I tried to implement an alternative using
> incomingRequestHandler(),
> but that was very complicated.  I think this simple
> timeout might work for
> some people.
> 
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
> 



 
____________________________________________________________________________________
Yahoo! Music Unlimited
Access over 1 million songs.
http://music.yahoo.com/unlimited


More information about the live-devel mailing list