Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rely on OS-native MDNS stack when possible #8

Open
CMCDragonkai opened this issue Jul 24, 2023 · 1 comment
Open

Rely on OS-native MDNS stack when possible #8

CMCDragonkai opened this issue Jul 24, 2023 · 1 comment
Labels
development Standard development r&d:polykey:core activity 4 End to End Networking behind Consumer NAT Devices

Comments

@CMCDragonkai
Copy link
Member

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

  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 CMCDragonkai added development Standard development epic Big issue with multiple subissues labels Jul 24, 2023
@CMCDragonkai
Copy link
Member Author

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

@CMCDragonkai CMCDragonkai added r&d:polykey:core activity 4 End to End Networking behind Consumer NAT Devices and removed epic Big issue with multiple subissues labels Aug 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
development Standard development r&d:polykey:core activity 4 End to End Networking behind Consumer NAT Devices
Development

No branches or pull requests

1 participant