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.
@jgkawell I've been leaning to just doing bespoke multicast UDP stuff personally :o
@jgkawell Is your code published somewhere I may read BTW?
@mauve Yes it is! Here's the relevant code but feel free to look around at the whole repo for context: https://github.com/home-cloud-io/core/blob/main/services/platform/daemon/host/mdns.go
@T_X I doubt the os impl would be all that different from libraries. Mdns is a pretty straightforward spec. The main thing to be weary of is conflicts with the OS since only one socket can bind to a given port for multicast udp. Meant that macos was very unreliable when software chose to bundle it's own
@mauve I was wondering if maybe overhead were lower when using the OS API because it might aggregate information in one packet? Also, for instance for #snapcast on my Debian right now I see an IPv4 #mDNS query from snapclient every second. So maybe people using the library instead of OS API might use inappropriately short intervals, too, creating more network overhead than necessary?
@T_X Jeeze that seems excessive. Imo you should just announce one network changes and initial lookup. unsure if os does rate limits though. Maybe I'll put together some sort of universal os level mdns thing one of these days
@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. 💀
@mauve I tend to agree. I'm working on a project that uses mDNS and after ending up with issues with certain OS's failing to work with my Go module implementation I shifted to just doing it through Avahi on the host. It's been rock solid since.