Notes on service discovery XS/XO

[Martin Langhoff]

(Cross posted to the Sugar list, I am hoping to discuss this stuff
with the Sugar folks in Paris as well.)

I've reviewed the XS 0.6 / 0.7 development plans, and one area that I
have to address is service discovery: how does an XO figure out
cheaply (in network & RF terms) what services are available on this
network.

More importantly, how do 5K XOs in a crowded school (and crowded RF)
accomplish the same with minimal network use?

When ths issue was mentioned in the past there were some suggestions
of mdns/dns-sd. Last week I worked my way through the specs, avahi
docs and any information I could find of mdns/dns-sd in server-centric
and crowded wireless environments.

The short of it is that mdns/dns-sd make sense for a small,
underutilised network of peers. They assume that the network is a
cheap resource, that broadcast messages are cheap, and that there is
no coordinating server.

Square peg, meet roundness.

So my plan (targetting 0.7-ish, perhaps 0.6) is to use old,
unexciting, tried-and-true DNS. Oh the horror, I am so uncool, I don't
have a twitter channel either :-)

My plan looks as follows ...

On the XS side:

 -  The XS serves DNS names for services -- so we will continue
expanding the list of services. I'll put together a wikipage with the
domain names associated to each service.
 - DNS allows the server to additional data to clients on a request,
data that the server things that the client "will need soon". If
possible, I'd like to configure whatever DNS server we use to
"proactively" feed the whole list of local names, with long TTLs, to
the clients when they ask about 'schoolserver'. If you know how to
configure BIND, dnsmasq or djbdns (tinydns) to do this, I'm all ears.
 - The XS will publish a CJSON-encoded (and perhaps SSH-cert-signed)
list of services and protocol versions offered at
http://schoolserver/services - the server-side implementation will
appropriate http cache-headers, so for smart http client that knows
how to say if-modified-since or Etag can save significant traffic.

On the XO side:

 - On the NM ifup hook (which triggers when we associate to a new
network), if the network looks like the network we registered on (the
DNS search path matches the base domain of the schoolserver it is
registered against) then request http://schoolserver/services
 - The service list retrieved can be checked cheaply via a local cli
tool and/or a Sugar library call. This cli / Sugar library call also
answers cheaply "are we in an XS network?" question.
 - Tools can completely ignore these sugar/xo specific things and just
perform a dns lookup for the servicename, if it fails, the service
isn't offered :-) This is less network efficient but it is a valid
behaviour, and accepted for compatibility. Any tools that we expect to
be in use in dense environments should avoid these pointless lookups,
perhaps by using a wrapper that performs the local (cheap) checks.
 - For "under a tree" or "home use" scenarios, dns-sd/mdns are
fantastic. Unfortunately, in dense wireless scenarios they cause a
complete meltdown, so we want to ensure that XO/SoaS builds avoid,
stop and kill kill kill! any mdns/dns-sd activity when there's a
School Server.

If you've read this far - congrats! - this is all very wordy, but it
boils down to:

 - I'll use good old DNS plus an HTTP-served cheat-sheet. This keeps
the chatter down.
 - Using the cheat-sheet, the XO/SoaS client side tools can know
easily and cheaply whether they are in an XS network and what services
are offered.

and it's not that much work. But it is a key point on how we structure
the XO-XS interactions.

Comments? Suggestions? Hands ready to help implement?

cheers,




m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff