Broadcast support

[gavv]

(This was initially reported via mailing list: https://www.freelists.org/post/roc/ROC-over-BROADCAST-IP)

Sending datagrams to broadcast address is permitted only when SO_BROADCAST socket option is enabled. Without it, sendto() returns EACCESS if the address is broadcast.

The reason for this is the common convention to disable broadcast messages unless explicitly enabled by user to prevent accidental flood.

We can't determine if the address is broadcast by just looking at it, and we should follow the common convention of not permitting it by default. Thus, we should add a way to explicitly enable it.

We should add bool broadcast flag to SocketAddr, and --broadcast command-line option to roc-send, which sets the flag on sender's bind address. If the flag is set, UDPSenderPort should call uv_udp_set_broadcast() to enable broadcast on the socket.

Later we will also add corresponding flag to roc_endpoint API.

[gavv]

Fixed with d159cdf3bedcf0bf09e7048568fa43c38db91c19 and 328f330cafed835e7348c46076c13f949b994187.

However note that broadcast may work extremely bad on Wi-Fi. See these SO threads:

• https://superuser.com/questions/695813/
• https://stackoverflow.com/questions/1735952/

The reasons are:

• access point uses the lowest common denominator transmission speed of all supported or connected devices (depending on implementation);

• broadcast doubles the on-air bandwidth;

• broadcast and multicast frames are not ACKed and therefore not retransmitted; the service quality drops on noisy channels;

• broadcast and multicast traffic does not use the RTS/CTS procedure for reserving the media; the service quality drops even more.

In result, the packet loss ratio is very high for me when using broadcast on WiFi, and there are a lot of glitches. Unicast works pretty good at the same time.

This can be worked around by increasing latency on receiver (e.g. --sess-latency=500ms) and redundancy level (repair to source packet ratio) on sender (e.g. --nbsrc 20 --nbrpr 80).