Date: Tue, 22 Aug 2006 08:00:08 -0400 From: Pat Lashley <patl+freebsd@volant.org> To: Fredrik Lindberg <fli+freebsd-net@shapeshifter.se> Cc: freebsd-net@freebsd.org Subject: Re: Zeroconfig and Multicast DNS Message-ID: <3E654CC0217F90E20FCD806E@garrett.local> In-Reply-To: <44EAC40E.9000904@shapeshifter.se> References: <44E9F991.7020309@shapeshifter.se> <DD49A62B2AB4E38804FB10B6@garrett.local> <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se>
next in thread | previous in thread | raw e-mail | index | archive | help
> My responder does one thing (ok it's many things but anyway), it > responds to queries and it makes queries. A mDNS record is always > a mDNS record (shared or unique), at this point SD records are > treated as any other record. > > Long-term records can be configured with responderd.conf, it > supports dynamic variables such as $hostname, $ifaddr, $ifname etc. As has been pointed out, avahi also allows services to be defined in a config file. That's good; but it would be better if there were also a simple utility program that could add or remove records based on command-line parameters. Then it could be invoked by the rc script to better reflect whether or not the service is actually running. (And that means only one thing to change when enabling/disabling a service.) Of course, having the daemon itself add the service record is even better; but that requires modifying the code for each daemon; and getting those modifications accepted back into the main distribution for those daemons. A simple utility script makes it easier to integrate non-mDNS-aware daemons into a zeroconf-based environment. > Once the daemon is running, you are able to communicate with it > through a UNIX pipe socket. > Through this socket you're able to make queries, add/remove records, > dump/flush the cache etc. > Of course this allows you to create records through rc scripts on > start up and removal of records on shutdown. So basically, the command would be "echo '...' >> /path/to/pipe" ? That's certainly convenient; but I doubt that it is compatible with the other mDNS implementations. A common utility name and command-line API for that would make it much more likely that it would be adopted by the bundled rc scripts, even if the mDNS code is not bundled. (There's no reason that utility couldn't be a script > Creating a library that mimic the API of mDNSresponder or gmdns > around this pipe shouldn't be a problem, but I haven't studied any > of their APIs so I can't say for sure. > > IMHO, SD really needs a set of standardized library calls, an application that > wants to publish a SD record shouldn't need to > worry about which type of responder program that is running on the host. I believe that that's the point of the libdns_sd library in the mDNSResponder port, libgmdns in the gmdns port, and one of the several libraries in the avahi port. They provide the service announcement/discovery API to be used by applications. I haven't looked at either API; so I have no idea how compatible they are. It would certainly be helpful to have a common API so that the choice of which to use could be made at application-load time. As I investigate further, it appears that avahi is the most mature, feature-rich, and widely supported and adopted mDNS implementation. The only potential drawback would be the GPL. I've also discovered that Apple are moving the iCal server, Bonjour, and launchd to the Apache 2.0 license; which should be acceptable to those who don't like the GPL. And apparently the Bonjour client libraries are already BSD licensed. Overall, I think your work on the IPv4 Link Local Addressing is much more important and useful (and more likely to be adopted) than another mDNS implementation. The LLA is the one piece that is currently missing for FreeBSD. -Pat
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E654CC0217F90E20FCD806E>