<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: [Live-devel] When send() failed, the return
value of s</title></head><body>
<blockquote type="cite" cite><font face="Arial"
size="-1">    I'm wondering, why LIVE555 project
doesn't care about the return value of send().</font></blockquote>
<div><br></div>
<div>Because there's usually nothing meaningful we can do if
"send()" fails.</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite><font face="Arial"
size="-1">    I'm facing a problem these
days.</font></blockquote>
<blockquote type="cite" cite><font face="Arial"
size="-1">    My RTSP Server was connected via a
low speed network in RTP/TCP mode, and the client couldn't
get any complete image.</font></blockquote>
<div><br></div>
<div>Sorry, but if you're streaming over TCP, and "send()"s
are failing, then it must be because your OS buffers are overflowing,
because your stream's bitrate exceeding the capacity of your network. 
In that case, you lose.  End of story.  Don't stream over
TCP.  Stream over UDP instead.  Yes, you'll still lose data,
but at least the data loss will be on RTP packet boundaries.</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite><font face="Arial"
size="-1">    I check the return value of
send():</font></blockquote>
<blockquote type="cite" cite><font face="Arial"
size="-1">        on Linux :
"errno" will be 11 -> EAGAIN</font></blockquote>
<blockquote type="cite" cite><font face="Arial"
size="-1">        on Windows :
"GetLastError()" will be 10035 ->
WSAEWOULDBLOCK</font></blockquote>
<blockquote type="cite" cite><font face="Arial"
size="-1">    Ignore the error, and try to send()
again, it works.</font></blockquote>
<blockquote type="cite" cite> </blockquote>
<blockquote type="cite" cite>    <font
face="Arial" size="-1">Is there any reason why does LIVE555 not check
the return value of send()?</font></blockquote>
<div><br></div>
<div>Because, as I said before, there's nothing meaningful we could
do.  It sounds like you're talking about trying to implement some
sort of 'reliable retransmission' protocol on top of TCP.  Sorry,
but that's completely brain damaged.  TCP is already a reliable
protocol.  If it's failing, then your network must be inadequate
for your stream's bitrate.  You'll need a slower stream, or a
faster network.</div>
<x-sigsep><pre>-- 
</pre></x-sigsep>
<div><br>
Ross Finlayson<br>
Live Networks, Inc.<br>
http://www.live555.com/</div>
</body>
</html>