The default behaviour is to allow multicast, with a fallback of
disabling multicast altogether if the selected interface doesn't support
it. The trouble is that the default discovery configuration assumes that
multicast is available, avoiding the "well-known" port numbers and
avoiding sending any participant discovery messages via unicast. The
result is that the process will run in isolation, which is typically not
the desired result. (It is a quite annoying problem because it happens
on Linux when only a loopback interface is available. It appears that
multicast over loopback works fine, if only you try it, but the kernel
doesn't advertise it and so it doesn't get used.)
This commit changes two things: firstly, it this case it forces the
allocation of "well-known" unicast ports, and secondly, it automatically
adds the local interface's address to the discovery address set. This
way, at least communication inside the machine works.
(Note: AssumeMulticastCapable can be still be used to force it to treat
a Linux loopback interface has multicast capable. It is only the default
behaviour that has changed.)
With thanks to @jwcesign who did all the work except writing the commit
message.
Signed-off-by: Erik Boasson <eb@ilities.com>
69a493ebb3