d1ed8df9f3
This is a workaround for interoperability issues, ultimately driven by a Windows quirk that makes multicast delivery within a machine utterly unreliable if the transmitting socket is bound to 0.0.0.0 (despite all sockets having multicast interfaces set correctly) when there are also sockets transmitting to the same multicast group that have been bound to non-0.0.0.0. (Note: there may be other factors at play, but this is what it looks like after experimentation.) At least Fast-RTPS in some versions binds the socket it uses for transmitting multicasts to non-0.0.0.0, so interoperability with Fast-RTPS on Windows requires us to bind the socket we use for transmitting multicasts (which was the same as the one we use for receiving unicast data) also to non-0.0.0.0 or our multicasts get dropped often. This would work fine if other implementations honoured the set of advertised addresses. However, at least Fast-RTPS and Connext (in some versions) fail to do this and happily substitute 127.0.0.1 for the advertised IP address. If we bind to, e.g., 192.168.1.1, then suddenly those packets won't arrive anymore, breaking interoperability. The only work around is to use a separate socket for sending. Signed-off-by: Erik Boasson <eb@ilities.com> |
||
|---|---|---|
| .. | ||
| dev | ||
| manual | ||
| CMakeLists.txt | ||
| compare.pl | ||
| makernc.pl | ||