[Live-devel] Detecting network failure

[Roberts, Randy]

	Hi Jeremy, 

	When this happens do you, by chance, notice the CPU utilization
go close to 100% on your target?

I checked, and I don't experience this.

Mostly, I just need a way of knowing that stuff is erroring out, but as
far as I see, I don't get any feedback.  The stream never times out (I'm
using a DarwinInjector), none of the callbacks get fired (i.e.
ByeHandler/AfterPlaying), etc.  At this point I'm thinking I'll have to
make code changes to make this work correctly, but maybe Ross will have
some feedback.
 

I just pulled the network cable on my setup (RTSPoverHTTP)...I get an
EAGAIN returned from send() (as my TCP tunnel socket is non-blocking)...
the TCP connection hasn't timed out...the Socket buffer just fills up...

 

Do your send() calls fail inside sendRTPOverTCP() (with EAGAIN)? 

 

The current code checks, but doesn't return the status...it simply
returns after the first failed call. Note, it is a void return from
sendRTPOverTCP(), so you'd never know that data isn't making it down the
stack (nor that the connection is "broken").

 

Note, I didn't conditionalize my error handling for specific errno
returns...which I probably should have...and, it may be better to pass
the status further up, to allow for error handling at a higher, more
appropriate layer...Ross may have some ideas here (maybe a client
provided error "handler" function could be used).

 

In my case the send() call(s) fail with errno= broken-pipe once that
connection gets closed by the peer...that is the clue upon which my
experiment is triggering the cleanup (i.e. removing the socket).  The
status is returned at the same point that RTPOverTCP_OK would be set
FALSE in previous releases of code...as you've pointed out before, that
is a global, and doesn't work for multiple
connections/streams...however, the returned status should.

 

I believe both the RTP and RTCP sockets from the RTPInterface are
non-blocking, so your behavior should be same (send() returns EAGAIN,
after socket buffer fills up)...you could take action after some number
of retry attempts on the send??

 

Randy

 


 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100322/5a4cd2f4/attachment.html>