> While that sounds interesting and may be useful in its own right, a > centralized server isn't really desirable -- part of the nice thing of > zeroconf is moving to a decentralized environment, and ideally doing > it in a scalable fashion (which isn't trivial on hundreds of thousands > of cores, we certainly don't want unrestricted multicast in such an > environment lest we drown in our own vomit of multicast queries and > responses). Inferno also has a dynamic registry service available as > another example implementation. However -- I think embracing some > internet standards wouldn't be a bad thing -- DNS is certainly an > existing example of an external protocol we support even though we > could have invented our own. Extending the DNS support to mDNS and > DNS-SD shouldn't be that big of a deal -- and most of the hard work is > in defining the Plan 9 interface not actually writing the protocol > support. It would allow us to play nice with other systems, which may > be very beneficial in xcpu environments (which also currently suffers > from a static configuration), and in particular on our Blue Gene work > where front-end nodes are typically Linux or MacOSX workstations.
dns is a bad protocol to build on. it's not really secure and the security measures are onerous. not to be confused with a technical argument for or against building on top of dns, but it's worth noting that ndb/dns has been pushed just about as far as it can go. it tends to suffer from cache funnies and can leak memory. i'm hoping that i can get a chance to build a thread library based dns server in the near future. - erik
