Rely on OS-native MDNS stack when possible #8
Labels
development
Standard development
r&d:polykey:core activity 4
End to End Networking behind Consumer NAT Devices
Specification
When multiple DNS stacks are run in parallel, it creates a problem because every subseqeuent mdns stack has to perform multicast responses rather than a more efficient unicast response to multicast queries.
Furthermore it also results in an increase of the number of sockets being created... etc.
It's more efficient to rely on OS-native MDNS stacks when they are available on the platform.
We started out building out own MDNS stack as an always on fallback. But since we expect multiple PK agents to be running on a single computer, it's a good idea to rely on the OS native MDNS stack when they are available. It was just extra development cost to do this.
The exact connection to the OS native MDNS stack may need to be platform-native. Which means it's important not to try to load that code if we're not on the right platform. We will examine this first with desktop platforms, then eventually mobile platforms. Platform detection will be important then.
Remember dynamic platform detection is not always possible due to the lack of consistent APIs in JavaScript for platform/feature detection. In some cases it's only possible to know by the caller of MDNS to supply the platform that they want to use. Furthermore it does make sense for the caller to know this information... rather than embedding potentially flaky logic in this library for detecting the right platform.
Additional context
Tasks
The text was updated successfully, but these errors were encountered: