Open sole opened 9 years ago
Yes. From what I understand, there are two ways of going about this -- SRV records and TXT records. We need to implement support for both (ideally) which would make this implementation far more complete. However, in most cases, I believe that the service name implies the port number(s). For example, on Apple AirPlay-capable devices, they simply advertise one or more services related to AirPlay and it is supposed to be understood that the clients know what port number those services are listening on.
Another use I've seen for TXT records is on network printing services. These records can be used to advertise a printer's capabilities as well as things like their display name. Essentially, TXT records are just key/value pairs, so ideally, we should be able to parse to/from JSON objects.
I might as well share some links here I used while developing this library as they may prove to be useful to others who may want to help complete this implementation:
Multicast DNS https://tools.ietf.org/html/rfc6762
DNS-Based Service Discovery https://tools.ietf.org/html/rfc6763
A course document outlining a DNS packet structure http://www.ccs.neu.edu/home/amislove/teaching/cs4700/fall09/handouts/project1-primer.pdf
Also, on Mac OS X, you can download this "Bonjour Browser" application that uses the Bonjour mDNS/DNS-SD implementation to browse network services: http://www.tildesoft.com/
The chat example uses a hardcoded 8080 port for communicating between discovered peers, but when registering the service we're indeed specifying which port we intend to listen to. The
discovered
handler doesn't retrieve anyport
information.I wonder if this is a limitation of the protocol or something that is planned for the future as I saw some commented code re: SRV records that is using the service.port in https://github.com/justindarc/dns-sd.js/blob/02ddf0202c7b364bb0eec9e7453d173a3d7fe983/src/dns-sd.js#L182
hoping it's something to be implemented in the future--would make this way more flexible!