On Wed, 21.06.06 17:44, Christopher Blizzard ([EMAIL PROTECTED]) 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 <[EMAIL PROTECTED]> 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/ _______________________________________________ avahi mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/avahi
