System update spec proposal
Mike C. Fletcher
mcfletch at vrplumber.com
Wed Jun 27 12:26:26 EDT 2007
Alexander Larsson wrote:
> On Tue, 2007-06-26 at 15:03 -0400, Mike C. Fletcher wrote:
> I'm not sure what you mean here exactly. Discovery is done using avahi,
> a well known protocol which we are already using in many places on the
> laptop. The actual downloading of file uses http, which is a well known
> protocol with many implementations.
> The only thing i'm missing atm is a way to tell which ip addresses to
> prefer downloading from since they are close. This information is
> already availible in the mesh routing tables in the network driver (and
> possibly the arp cache), and its just a question of getting this info
> and using it to drive what servers to pick for downloading.
Ah, somehow in the discussions I'd come under the impression that the
only way the system would be allowed to work was a single-hop network
link on the mesh. If we already have the information and can always
have a fallback, even if it means going a number of hops across the
network. Looking back I see that was actually a discussion on bandwidth
characteristics that wasn't intended to imply an absolute requirement.
I'm reasonably happy with the approach of using Avahi and only using the
network topology to inform the decision on which server to use.
That said, I would be more comfortable if the fallback included a way
for the laptop to check a well-known machine every X period (e.g. in
Ivan's proposal) and if there's no locally discovered source, use a
publicly available source as the HTTP source by default
>> Hmm, interestingly I see "using our own tool" as a disadvantage, not a
>> huge one, but a disadvantage nonetheless, in that we have more untested
>> code on the system (and we already have a lot), and in this case, in a
>> critical must-never-fail system. For instance, what happens if the user
>> is never connected to another XO or school server, but only connects to
>> a (non-mesh) WiFi network? Does the mesh-broadcast upgrade discovery
>> protocol work in that case?
> Avahi works fine for these cases too. Of course, since it was originally
> created for normal networks. However, if you never come close to another
> OLPC machine, then we won't find a machine to upgrade against.
Sorry, should have been clearer that the later case (not coming close to
another OLPC) was the one I was concerned about. I realise such
situations will represent only a small percentage of children, but a
small percentage of 50,000,000 or so users is a huge number of people to
have to teach how to manually upgrade their machines.
> Its quite
> trivial to make it pull from any http server on the net, but that has to
> be either polled (which I don't like) or initiated manually (which might
> be fine).
I'd advocate that the piece of Ivan's proposal wherein a central
mechanism allows even a completely isolated machine to find and update
automatically is a good idea. It's a fairly trivial proposal that way,
in the same check to see if we've been stolen download 4 bytes (or so)
telling us the currently available version. If we can't get it locally
after X period, try to get it from the server (using whatever protocol,
be it your own, rsync, BitTorrent or Telepathy (cute, I was actually
writing "telepathy" there and then realised it was the name of our
networking library)). That is, I'd like to see a robust, automatic
mechanism for triggering the laptop's search and a fallback position
that allows for resolution even in the isolated-user case that doesn't
require user intervention.
Mike C. Fletcher
Designer, VR Plumber, Coder
More information about the Devel