[avahi] scalability of avahi (or mdns-sd in general)

[Lennart Poettering]

On Wed, 21.06.06 17:44, Christopher Blizzard (blizzard at redhat.com) wrote:

> 
> Lennart Poettering wrote:
> >You could make use of DNS-SD on unicast DNS. This requires a central
> >server, though. And unfortunately, Avahi does supports this in a
> >read-only fashion only, right now. (However, full write support is
> >being worked on.)
> >
> 
> I've been putting together a list of things that we need for One Laptop 
> per Child, and this functionality is on that list.  Can you share who is 
> working on it?

Sure: Federico Lucifredi <flucifredi at novell.com>

For OLPC DNS-SD over unicast DNS is probably not what you want, since
it requires a central server.

Will you attend GUADEC? Due to the generosity of the Gnome Foundation
I am now attending, too. We could dicuss this topic in person, if you
want.

In the last weeks I thought a little about how Avahi could be used in
OLPC. Unfortunately (and honestly), I came to the conclusion that
mDNS/DNS-SD is not suitable for the 100$ PC. mDNS/DNS-SD is not
designed for mesh networks and the traffic imposed is much higher than
it could be.

I had some ideas how to design a similar system, which reuses the good
things from mDNS/DNS-SD (such as the relative compatibility with
traditional DNS) but tries to fix the negative things (such as
traffic, latency, the impossibility to route it properly, needlessly
complex (and buggy by design!) algorithms, no AXFR) that I found while
making Avahi the best mDNS/DNS-SD implementation around. ;-)

I came up with a much simpler design which should do most things
mDNS/DNS-SD does, while being API compatible to a certain degree. The
best thing however, is that it should be much easier to implement, and
the resulting code should be much smaller.

Roughly my idea is to scrap the idea of a fully peer-to-peer
system. Instead my design would elect a master browser (much like SMB,
but not as broken by design), which does most of the work. Any peer on
the net can become a master browser. The master browser is responsible
for maintaining the full zone file for the LAN. The election is very
simple: if a host sends out a query and doesn't get a response in,
let's say, 5s it automatically becomes the new master browser. In case
more than two master browsers appear on the net the one with the lower
IP address loses. Multicast queries are only used when a client joins
a network and looks for a master browser or when the master browser
wants to broadcast the zone file (or updates for it)
periodically. Everything else is done exclusively via unicast
DNS. Every client maintains its own copy of the zone file. Thus host
name lookups and service enumerations can be done immediately and
without actually imposing traffic on the network. 

>From outside this design appears to be a peer-to-peer design, but
internally it's actually a client-server design. One, however, where
the role of the server may change quickly and is dynamic. The actual
zone files contain normal DNS data, just like mDNS/DNS-SD. In fact my
design would only replace "Multicast DNS" but keep "DNS-SD".

Anyway, I am pretty sure this design has some limitations, too. I
haven't implemented it, so I don't know where the practical
deficiencies are. It was fun, however, to concieve it.

Lennart

-- 
Lennart Poettering; lennart [at] poettering [dot] net
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/