From owner-freebsd-net@FreeBSD.ORG Mon Aug 21 23:08:46 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 A6B3B16A4DE for ; Mon, 21 Aug 2006 23:08:46 +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 2159043D49 for ; Mon, 21 Aug 2006 23:08:41 +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 1GFIv4-0004oq-Qz; Mon, 21 Aug 2006 16:12:04 -0700 Date: Mon, 21 Aug 2006 16:06:08 -0400 From: Pat Lashley To: Fredrik Lindberg Message-ID: <9C04919EE684029A410DE208@garrett.local> In-Reply-To: <44EA1926.2000501@shapeshifter.se> References: <44E9F991.7020309@shapeshifter.se> <44EA1926.2000501@shapeshifter.se> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: dbc2d31c1a3da52922e7a4293aa998cd24823ecb 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.2 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: Mon, 21 Aug 2006 23:08:46 -0000 > > Actually, that is IPv4 Link Local Addressing. Zeroconfig includes that, > > Multicast DNS, Service Discovery and anything else that removes the need > > for manual configuration. > > Yeah, I actually know that. It's just that I've developed a bad habit of > calling it zeroconfig in the absence of a short name, calling it > "ipv4 link local addressing" every time tends to get a bit tedious. > But I should not have done that in my previous mail, my apologies. After a quick look at your website, I figured you were probably aware of the correct usage; but thought that it might be a good idea to clarify the point for others on the list who might be new to the idea. > > I'm very glad to hear that somebody is working on IPv4 Link Local for > > FreeBSD. > > > >> Multicast DNS is DNS without a server, you can think of it as mixing > >> ... > > > > Doesn't the net/mDNSResponder port handle both mDNS and (m)DNS-based > > service discovery? Is it missing some functionality that can't be easily > > handled by a wrapper? (E.g. An nss_mdns that uses their libdns_sd.so) > > > > I didn't know there was a port of Apples daemon and I'm sure it > works just fine. The only thing that might be an issue is licensing > terms, at least in embedded solutions. My code is under a BSD license. Actually, the Apple license looks pretty reasonable; even for embedded applications. > I'll continue to hack on my responder anyway, as it's not that > far from completion. Since sending that email, I also discovered that there's a net/gdns port for the GNU version. But it appears to be under the GPL; which would be more of an issue. I just thought that it might be easier to work with one of these established projects. > The service discovery part is just a set of records in the responder > which it responds to, a service discovery client/agent is needed to > find announced records. The Apple way seems to assume that the individual applications will be linked with the service discovery library. I'm not sure that they even provide a method for the end-user to browse all available services. There is a postcard-ware third-party app called Browsejour from bleepsoft; but I'm sure that it's GUI is OS X specific. A browsing utility would certainly be useful; but if I were starting such a project, I'd write it to use one of the existing libraries from the ports. (Ideally choosing which at build time.) Of course, you aren't just starting your project, you're fairly well along; so I can understand your reluctance to switch. Is your library API fairly close to the one in mDNSResponder or gmdns? If so, it should be fairly easy to make your apps work with whichever library is installed. (I'm just thinking ahead to the point where projects like Apache, Firefox, and various GNOME apps have added service announcement/discovery and sysadmins are asking themselves why they need three different mDNS libraries installed at once...) Also, you mention the discovery client/agent; but not the advertisement. I'd really like to see an easy way to advertise services without having to modify the daemons to announce themselves. I'm particularly thinking of long-running daemons for services like http, ssh, ftp, etc.; where the service is generally made available as part of the boot sequence. It would really be great if the service advertisement could be done as a one-line addition to their rc scripts. (Something like: '[ -x /path/to/announcer ] && announce service' would be safe even if the mDNS stuff isn't installed. Actually, I suppose you'd also want a line to revoke the annoouncement in the 'stop' section. ) -Pat