Hot take, #P2P protocols shouldn't use MDNS for peer discovery if they don't plan to use the OS provided APIs for it. Only one process can reliably bind the UDP port necessary for it and it quickly leads to conflicts. At the very least you should use a custom port to avoid conflicting with the OS.
@mauve also, just played around with #socat and #reuseaddr and #reuseport a bit. For #UDP #unicast, this did not help, only one socat client receives the packet on Linux. However with #IPv6 #multicast on Linux this seems to work fine, receiving with multiple clients listening on the same UDP port on the same host when using SO_REUSEADDR/SO_REUSEPORT?
@T_X Sadly I haven't done much reading on the IPv6 case but in the IPv4 case I think you could cheat by using the reuseaddr flag since it treats it as a different socket in the table used to track sockets internally but BSD had some difference in it where that wasn't the case. Sadly my memory is hazy since it's been like 2 years since I looked.
I think for local processes a single daemon that does the multicast stuff with a domain socket to talk to it from multiple processes is the way to go.

@T_X Oh wow it was actually 4 years ago. ๐Ÿ’€

https://github.com/brave/brave-browser/issues/9630

How to proceed with patch for MDNS fix ยท Issue #9630 ยท brave/brave-browser

Description I'm currently working on fixing the MDNS peer discovery issue in ipfs-companion. In order to fix this I discovered that we needed to change Chrome's UDP socket API to have a flag to ena...

GitHub