[Live-devel] Increasing OutPacketBuffer::maxSize results in sendto() returning WSAEWOULDBLOCK

[James Bowley]

Thank you for your quick reply.  I would like to clarify a few points if 
possible because I am not sure I explained myself correctly in the 
previous message.

I believe the packets are not being written to the server socket and are 
not being lost on the network.  To check this I have included the following

fprintf(stderr, "writeSocket(%d), sendTo() error: wrote %d bytes instead 
of %u:, %i ", socket, bytesSent, bufferSize, WSAGetLastError());

on line 404 of GroupsockHelper.cpp, just under

socketErr(env, tmpBuf);

And

fprintf(stderr, "Packet count %i, Seq num %i\n", fPacketCount, fSeqNo);

on line 374 of MultiFramedRTPSink.cpp.

And then run the modified LIVE555 Media Server on one machine with 
openRTSP (with -d 10) on another and wireshark running on both machines.

If I request a .264 file with openRTSP, recorded from an ip camera which 
unfortunately has large iframes, I observer the following output from 
the Media Server

writeSocket(404), sendTo() error: wrote -1 bytes instead of 39:, 10049 
Packet count 0, Seq num 65261
writeSocket(404), sendTo() error: wrote -1 bytes instead of 18:, 10049 
Packet count 1, Seq num 65262
writeSocket(404), sendTo() error: wrote -1 bytes instead of 699:, 10049 
Packet count 2, Seq num 65263
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:, 10049 
Packet count 3, Seq num 65264
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:, 10049 
Packet count 4, Seq num 65265
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:, 10049 
Packet count 5, Seq num 65266
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:, 10049 
Packet count 6, Seq num 65267
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:, 10049 
Packet count 7, Seq num 65268
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:, 10049 
Packet count 8, Seq num 65269
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:, 10049 
Packet count 9, Seq num 65270
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:, 10049 
Packet count 10, Seq num 65271
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:, 10049 
Packet count 11, Seq num 65272
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:, 10049 
Packet count 12, Seq num 65273
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:, 10049 
Packet count 13, Seq num 65274
*writeSocket(412), sendTo() error: wrote -1 bytes instead of 1456:, 
10035 Packet count 105, Seq num 21061*

Note: I get the same output with and without wireshark tapping the 
connection.

The first send errors of type 1049 (*WSAEADDRNOTAVAIL) *always occur and 
do not effect the stream or the reported packet loss.  I have included 
them just for completeness in case I am wrong on this.

The last error of type 10035 (*WSAEWOULDBLOCK) *occurs only when I have 
increased OutPacketBuffer::maxSize to accommodate the large iframes in 
the .264 video (removing the truncation). This description for this 
error implies the socket is busy and I should try again later:

"Resource temporarily unavailable.
     This error is returned from operations on nonblocking sockets that 
cannot be completed immediately, for example recv when no data is queued 
to be read from the socket. It is a nonfatal error, and the operation 
should be retried later. It is normal for WSAEWOULDBLOCK to be reported 
as the result from calling connect on a nonblocking SOCK_STREAM socket, 
since some time must elapse for the connection to be established."

OpenRTSP then reports a packet loss of 1.   Wireshark on both ends of 
the connection records the same number of RTP packets however the packet 
with sequence number 21061 is missing.  This appears to confirm that 
this packet, as reported by the application, is not written to the 
socket.  Am I incorrect in this assumption?

In addition I have observed a similar pattern when using the proxy 
server.  If I request 1-2 streams from the proxy then I do not observer 
any of the above errors, however when I increase this number I get lots 
of 10035 error codes and reported packet loss from the openRTSP application.

I have tested this on Windows 8.1 and 10 in both directions. Whilst I 
understand, if I have not made a mistake in my assumptions, that this is 
probably a Windows issue and outside the remit of live555 I would 
appreciate any help in resolving/re-transmitting the lost packets I am 
observing.

Thank you again,

James.

On 16/01/2020 20:40, Ross Finlayson wrote:
> The reason that you’re seeing lost packets has nothing to do with "OutPacketBuffer::maxSize”, nor with “sendto()”.  It’s simply because the streaming is done over UDP, a ‘best efforts' datagram protocol, in which data delivery (unlike in TCP) is not guaranteed.
>
> That’s simply how real-time (RTP) streaming works.  Time-sensitive data is sent via an unreliable datagram protocol.  Packets can get lost.  If a packet gets lost, then it often would not make sense to try to retransmit it, because the data is time-sensitive.  (By the time the receiver (e.g., media player) ended up getting it, it would no longer be of any use; the media player will have already moved on to a later frame.)  (For very low-latency connections (e.g., over a LAN), there are feedback-based retransmission mechanisms available for RTP; however, we do not implement these.)
>
> This confuses some people who are relatively new to the Internet, because most people's exposure to the Internet these days is solely via the World-Wide Web (HTTP), in which data is sent using a reliable protocol (such as TCP).  But datagram-based streaming is different.
>
> If data loss is a ‘deal breaker’ for you, then you should not be using RTP, nor our software.  Instead, transfer your stream over TCP, using something like “nc”, or “scp”.
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20200117/34f6fcef/attachment.htm>