System update spec proposal

[Mike C. Fletcher]

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.

Enjoy,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com