On Mon, Aug 31, 2009 at 9:55 AM, Francisco J Ballesteros<n...@lsub.org> wrote:
> Hmmm. we did that for FS processes on Plan B. I mean, keep a
> dynamic version of a registry. It kept the list of volumes available at a
> central place.
>
> I think it can be used as is on Plan 9, without changes.
>
> There was a program (I think it was called adsrv; not sure, it´s on the
> Plan B man pages) were file servers could keep an open file as long as
> they were alive.
>
> We didn´t do load balancing but it shouldn´t be hard to add that to
> this program.
>
> If there´s interest I can dig in our worm (although it should be also
> on sources).
>
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.
-eric
