Choosing a module for DNS-SD

[gmaclennan]

Description

The purpose of this issue is to document the reasoning behind which module we use for DNS Service Discovery over multicast DNS (as defined in RFC 6762 and RFC 6763).

I have done extensive testing on my local network of the different modules available, and the most reliable appears to be bonjour-service. What I have tested:

• Browsing for a service and checking service up and service down events are emitted, without duplicates
• Checking the correct IP addresses are resolved when browsing for a service
• Browsing for services advertised on different machines on my local network with avahi and ciao
• Advertising a service and checking the correct hostnames are advertised
• Browsing for the advertised service using dns-sd CLI and Discovery - DNS-SD Browser locally, and avahi on a different machine on my local network.

Results for other options:

ya-dns-sd

This looked promising because it is used by another p2p project and written in modern code which is easy to read, but I have only been able to get it working with lots of patches - it doesn't seem stable enough at this time to rely on.

• The dgram server is created without the option reuseAddr which causes an error when trying to bind the socket if there is an existing mDNS service running on the device (common)
• There is a race condition on startup of the advertise if called before the socket is listening.
• There is a bug for advertise when resolving ownAddress that does not correctly parse the data returned from os.networkInterfaces().
• There is a bug with browse that causes duplicate service up events when a service is going down
• There appear to be memory leaks with subscriptions being added but not removed.

dnssd

The original module is no longer maintained, so we used a fork maintained by Gravity Software. We have used this in the past, but in testing it is buggy, it does not seem to be maintained, and is not widely used (416 downloads per month).

• Browsing does not consistently correctly resolve the IP addresses of advertised services (sometimes IP addresses are missing from the serviceUp events)
• It's possible to manually resolve browsed services, although the documentation is lacking and the resolveA() function is not correctly exported.
• There is not documented way to close the dgram socket after it is opened, and a single socket is used globally, which makes testing hard (because all new instances use the same socket). Because the socket can't be closed, tests can hang without ending.
• Reading through the codebase there is a lot of "dead code" and incomplete documentation.

@homebridge/ciao

This is well-tested (including Apple's bonjour conformance testing), but it is only an advertiser - it does not have a browse functionality. It is also widely used (11,746 downloads per month). It works very well in testing, but using a separate browser results in MDNS responders being created (one for ciao, and one for whichever browser we use) which results in a lot of unnecessary traffic and potential bugs.

bonjour-service

This is the most widely used dns-sd library, with 7m downloads per week. It does not have very extensive tests, but I assume that wide usage serves as a test to some extent. In testing it worked as expected, although there is some trickiness to how hostnames and instance names are configured so that it can be browsed as expected by other dns-sd browsers.

• It does not have an option for excluding ipv6 addresses from service advertisements (ciao supports this option). This can be patched by skipping adding AAAA records, or we can filter ipv6 addresses when browsing (ideally we would not advertise ipv6 because we are not listening on ipv6)
• There are some unresolved bugs related to hard-to-replicate edge-cases that result in discovery not working that seems to happen on certain machines and networks when the browser is created after the advertisement.

[gmaclennan]

Marking as resolved since implemtation using bonjour-service is underway in #177