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 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel