Early this week, the Avahi team
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
"Rendezvous"), Multicast DNS
(mDNS) and DNS Service Discovery
(DNS-SD) from the Zero Configuration
(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
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
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
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.
to post comments)