From owner-freebsd-net@FreeBSD.ORG Tue Aug 22 15:01:16 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A172416A4DD for ; Tue, 22 Aug 2006 15:01:16 +0000 (UTC) (envelope-from patl+freebsd@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AB9043D66 for ; Tue, 22 Aug 2006 15:01:03 +0000 (GMT) (envelope-from patl+freebsd@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[192.168.1.121]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GFXnd-000JIs-Sf; Tue, 22 Aug 2006 08:04:24 -0700 Date: Tue, 22 Aug 2006 08:00:08 -0400 From: Pat Lashley To: Fredrik Lindberg Message-ID: <3E654CC0217F90E20FCD806E@garrett.local> In-Reply-To: <44EAC40E.9000904@shapeshifter.se> References: <44E9F991.7020309@shapeshifter.se> <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: a8d7e94cdfe9daa44db7ff9a8495f212c1006a71 X-Spam-User: nobody X-Spam-Score: -4.1 (----) X-Spam-Score-Int: -40 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-4.1 points total, 5.0 required) 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date 0.1 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Zeroconfig and Multicast DNS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 15:01:16 -0000 > 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