Weekly Edition
Return to the Front page
| |||||||||||||
Guten Tag from Avahi
Early this week, the Avahi team announced
the 0.1 release of Avahi, dubbed "Guten Tag."
Avahi is a framework for service discovery on local networks, using the
same specifications as Apple's Bonjour (formerly
"Rendezvous"), Multicast DNS
(mDNS) and DNS Service Discovery
(DNS-SD) from the Zero Configuration
Networking (Zeroconf) working group.
So, Avahi allows programs to publish services that are available and to
discover services that are available on other machines. As an example, a
user could find local printers without needing to know their IP address, or
which computers are publishing file shares.
We asked two of the Avahi developers, Trent Lloyd and Lennart Poettering, about this release and what we could expect from future releases. Avahi is a framework, and is meant to be used by other programs that have a need for mDNS/DNS-SD. It uses a D-BUS API, with "implicit bindings" for Python, Mono and many other languages, according to Poettering. According to the release notes, a few of the "SHOULDs" for mDNS were not implemented. We were curious about what hadn't been implemented, and whether they planned to implement them in the future. Poettering explained why some of the "SHOULDs" were not in this release:
This depends. Some of the missing "SHOULDs" are difficult to implement (or
at least I'm to lazy to implement them for what it's worth), some of the
"SHOULDs" are currently discussed to be removed from the RFC entirely, some
don't apply to our implementation and others I consider questionable.
Poettering also identified three "SHOULDs" in the mDNS specification that are not implemented in the 0.1 release of Avahi:
Unicast response bit generation (Avahi honours it on incoming queries but
doesn't set it on outgoing queries). According to Marc Krochmal (one of the
two Apple guys behind mDNS/DNS-SD) they're considering the complete removal
of this feature, as its added complexity outweighs the gain.
An extra delay should be applied when relying to packets with the TC (truncation) bit set. This is on the TODO list. It's a fairly new addition to the spec (only available in the spec as of 7th June 2005). Passive observation of failures. This must be slipped from my mind completely. I didn't have that one on my list. Since avahi doesn't implement this (optional) feature at all, the "SHOULDs" don't apply to Avahi right now. (Though I added this to the TODO list now) Despite the low version number, and the fact that a few of the "SHOULDs" have not yet been implemented, Lloyd said that this release is actually quite usable:
Well the low version number is a bit of a misnomer it terms of featureness,
it does have quite a lot in it, there is some work for 0.2 to provide a
couple new resolver interfaces to the DBUS for better handling of services
changing their information, and it will certainly contain bug fixes.
Poettering also noted that Avahi "has lots of uncommon features that even Apple's stack doesn't have." One feature that Poettering highlighted is "avahi-dnsconfd," which "allows the configuration of unicast DNS servers via mDNS in a DHCP-like fashion. This is especially useful on IPv6 where address autoconfiguration is available out-of-the-box, but DNS server configuration currently isn't." We also asked if the low version number indicated that Avahi would be undergoing major API changes. Poettering said that he doesn't see "any major changes coming for the near future" but that there would probably be some API additions.
One thing that Poettering stressed is that Avahi is not GNOME-centric or KDE-centric. "We currently ship a glib adapter for our libraries, but this purely optional... We are interested in adoption of Avahi in all desktop environments, including both GNOME and KDE. Admittedly the core developers of Avahi are all GNOME people, but that's just personal preference." There are other implementations of mDSN/DNS-SD available, but not under what many would consider a "free" license. Avahi is available under the LGPL, so it should be usable by nearly any project that would care to incorporate Avahi. At the moment, Avahi is only available for Linux. The only stumbling block appears to be netlink, according to Poettering and Lloyd. Poettering says that "as soon as the BSD compatible replacement for netlink is in place, porting to other kernels should be really simple." It should be interesting to see how Avahi is incorporated into Linux applications and distributions. The ability to easily advertise printing, file-sharing and other services for desktop users -- putting Linux on par with Mac OS X -- is one more component in helping to secure Linux's place on the desktop. (Log in to post comments)
Not yet even a proprosed IETF standard Posted Aug 25, 2005 13:21 UTC (Thu) by nealmcb (subscriber, #20740) [Link] Sounds like a useful development, and thanks for the update. But it looks to me like the standardization effort hasn't even gotten out of the "draft" stage.All drafts contain this warning:
'Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."'
So discussing whether an implementation implents various requirements needs to be understood in that context. It may be that in this case this stuff is pretty well agreed on. Or not. But just remember that it can really hurt interoperability to have widely deployed software that conflicts with a standard when it does get published.
See RFC2026 http://ietf.org/rfc/rfc2026.txt for more on how the IETF standards process works.
Not yet even a proprosed IETF standard Posted Aug 25, 2005 14:05 UTC (Thu) by nedrichards (guest, #23295) [Link] >But just remember that it can really hurt interoperability to have widely deployed software that conflicts with a standard when it does get published.
You mean like every Mac made since OS X 10.2?
Not yet even a proprosed IETF standard Posted Aug 25, 2005 23:26 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] The IETF process requires working implementations, which means that they don't expect people to wait around until the spec is approved before implementing something. If the spec changes, I'm sure that the open source implementations will be changed to match. Sometimes proprietary vendors might decide not to change in the hope that they can lock people in, but for something like zeroconf, it only works if everyone can speak the protocol.
Not yet even a proprosed IETF standard Posted Aug 26, 2005 0:08 UTC (Fri) by nealmcb (subscriber, #20740) [Link] I agree. Sorry if it sounded like I was criticizing the implementors. My only point was that the _article_ leaves the impression that there is a published standard against which to evaluate the implementation. E.g. it talks of "using the same specifications as Apple's Bonjour". In fact there is not yet a standard. The latest draft is from June, after Apple shipped Bonjour, and there will likely be more drafts to come. And note it often goes the other way around in the IETF - the drafting of the standard relies in part on implementation efforts and experiences like this one.
I just thought the reader needed to know how much all of this is still potentially in flux.
Not yet even a proprosed IETF standard Posted Aug 31, 2005 1:02 UTC (Wed) by kitterma (guest, #4448) [Link] A lot of discussion about why on the main ietf list starting here:
http://www1.ietf.org/mail-archive/web/ietf-announce/curre...
In summary, here:
http://www1.ietf.org/mail-archive/web/ietf/current/msg373...
Scott K
IETF DNSEXT working group prefers LLMDR over mDNS Posted Aug 31, 2005 22:48 UTC (Wed) by nealmcb (subscriber, #20740) [Link] When I posted my first comment I was just reacting to what seemed to be imprecise wording in the article. Thanks to the head's up by kitterma, I now see that in fact the IETF DNSEXT working group is proposing LLMDR instead of mDNS. We'll see how the IESG views the debate soon.
Wikipedia has this to say (chime in if you can!):
http://en.wikipedia.org/wiki/Zeroconf
Here is another perspective by Keith Moore:
http://www1.ietf.org/mail-archive/web/ietf/current/msg371...
I don't know which is better - just trying to avoid misunderstanding.
Exemplary Posted Aug 25, 2005 22:07 UTC (Thu) by ncm (subscriber, #165) [Link] If only all Free Software projects were as well-run as this one...
Congratulations on an excellent debut, guys!
|
|||||||||||||