> I tried to fix the problem by this way:
>
> - sendResult = send(socketNum, (char const*)(&data[numBytesSentSoFar]),
> numBytesRemainingToSend, 0/*flags*/);
> +
> + do {
> + sendResult = send(socketNum, (char
> const*)(&data[numBytesSentSoFar]), numBytesRemainingToSend, 0/*flags*/);
> + } while(sendResult == -1 && envir().getErrno() == EAGAIN);
No, you can't do this (and there's not a 'problem' that needs fixing)! If the
TCP connection gets blocked permanently (e.g., because the receiving client has
stopped running, or has a cable disconnected), then you can't just sit in a
loop, attempting to send() over and over again. That would starve out all
other server activity.
There's no 'bug' or 'problem' here. The "EAGAIN" error occurs when the sending
OS's TCP buffer is full - which occurs if the stream's bitrate exceeds (at
least temporarily) the capacity of the TCP connection. When this happens, the
only solution is to discard outgoing data. Our code does so by ensuring that
if/when data gets discarded, the discarded data will be a complete RTP (or
RTCP) packet - equivalent to the loss of a packet if you were streaming over
UDP.
Some people seem to think that streaming over TCP is a 'magic wand' that will
avoid all data loss, regardless of the bitrate of your stream and the capacity
of your network. But that's impossible. If your stream's bitrate exceeds the
capacity of your network, you *will* lose data. The only way to prevent this
is either to transmit a slower stream, or use a faster network.
Yet again, let me remind everyone that streaming over TCP is something that you
should be doing *only* if you are behind a firewall that blocks UDP packets
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
