search

agnat / node_mdns

mdns/zeroconf/bonjour service discovery add-on for node.js
http://agnat.github.com/node_mdns
MIT License
870 stars 146 forks source link

Favor dns_sd DNSServiceGetAddrInfo on linux as well #250

Open tadam313 opened 3 years ago

tadam313 commented 3 years ago

I'm wondering whether we should prefer to use the dns_sd DNSServiceGetAddrInfo function (HAVE_DNSSERVICEGETADDRINFO flag) over the node implementation (cares_wrap) on linux-ish systems as well if available. I know that "avahi compat" library does not have this function, however, we can still compile Apple's mDNSResponder Posix version on certain linux distros which does have it. I have a use-case on Synology DSM (which is recognized as "Linux" by node gyp) where I had to use Apple's library (avahi is not available) and need to force using DNSServiceGetAddrInfo (by manually defining HAVE_DNSSERVICEGETADDRINFO in binding.gyp). Unfortunately, the node implementation did not work, I was constantly getting errors like { code: -3008, errno: -3008, syscall: 'getaddrinfo' }. However dns_sd implementation works perfectly fine.

This makes me wondering should we define HAVE_DNSSERVICEGETADDRINFO based on capability on Linux? For now, it's completely missing and assumed that linux systems use avahi library every time. For example, we could use nm to check whether DNSServiceGetAddrInfo is available in libdns_sd.so or not? WDYT?

The alternative would be to target Synology DSM OS exclusively with some condition and define this flag there, but not sure at the time how could we do it.

agnat commented 1 year ago

Hi @tadam313,

apologies for being unresponsive. Must have slipped through...

Yes, I like it. Detecting the actual dns_sd implementation would be great and I'm sure I've tried. However, IIRC a symbol based approach (configure, nm, dlopen, etc) does not work. Unfortunately avahi actually has that symbol but the function reports an error and terminates the process (again IIRC).

Now that it's on my radar let me think about it some more. If auto detection at runtime becomes too awkward at least there should be a way to select the implementation without modifying files... preferably at runtime, without recompiling. Maybe an environment variable? WDYT?

tadam313 commented 1 year ago

yeah I think we'd need to do the runtime auto detection in C++ code maybe using externals and weak references, but not sure at this point 🤔 By any means feel free to give it a shot it would be interesting to do some digging in this area 🙂 On the other hand the easiest would be to use an env var for sure and define a condition in binding.gyp for that env var. The only downside of that it would be easy to miss as it would be buried deep and not visible on the interface, but at least there is a solution without modifying the source