Use non-blocking socket about amazon-kinesis-video-streams-webrtc-sdk-c HOT 3 CLOSED

Yes we need to do something better long-term, but we have the following things I haven't thought through fully yet.

• Do we buffer? If we do how much? Do we let users determine what to throw away?
• In most cases we are doing UDP, so I don't believe it will be blocking. In the cases we do TURN via TCP it will be a problem though.

There might be other issues, but haven't really tackled this fully yet.

from amazon-kinesis-video-streams-webrtc-sdk-c.

Yep, for UDP, that might not be a problem unless the send rate is reaching the network max. speed.
With TCP, it could be an issue. We can control the socket send buffer size via SO_SNDBUF , so no ned for another buffer in user space. Then might be throw away the packet once the socket buffer is full, i.e. EAGAIN or EWOULDBLOCK return in send.

The size of the socket send buffer size should be adjust according to the data type, a 1080p video streaming vs a voice only streaming need a different size. Possible buffer 100ms of data at most to ensure latency is minimum.

from amazon-kinesis-video-streams-webrtc-sdk-c.

That sounds like a good idea to me! We can probably just allow SO_SNDBUF to be set via the Public API. The less code the better :)

In the future if we have to allow custom 'leak' behavior like GStreamer's queue (upstream vs downstream) we can always revisit.

from amazon-kinesis-video-streams-webrtc-sdk-c.