Rely on OS-native MDNS stack when possible

[CMCDragonkai]

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

• 2

• 3

• 4

• 5

Tasks

1. Parameterise the platform instantiation or figure out a dynamic way of doing platform plus feature detection for existing MDNS stacks.
2. Create adapters (possibly using top-level await) to load the right implementation.
3. Fallback on the default MDNS stack when none is available.

[CMCDragonkai]

Any research information or technical manuals you found @amydevs you should then link to the subissues.