Actually things are not as simple as that. The first problem is that the table of neighbors in fwt_list_neigh does not get updated to remove nodes that are no longer reachable, so after a while you will be left with stale entries and you will either have to reset the table with fwt_reset, or try to find out who is still there. I'm not sure if this changed since last month, but if not, then both solutions seem like a bad hack to me.
The second problem is that, even if you have a completely up-to-date list of direct neighbors, link quality among them still can vary greatly and you may end up trying to get something from a far neighbor at 1Mbit, while there are others much closer with better link quality. I wrote some code to deal with both problems, so that you have a qualitative hop count (offering real numbers instead of just integers for hop count) for all nodes in the mesh without broadcasting/multicasting any frames. The following snapshot only shows one neighbor with perfect reception. http://web.media.mit.edu/~ypod/teleporter/dump.png I can clean up the code and upload it somewhere. Dan Williams wrote: >> 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. >> > > So, like michail said, do something like: > > n = 0 > while (True) { > buf = output of (iwpriv msh0 fwt_list_neigh n) > if (buf == "(null)") > break; // all done > > <parse buf into fields> > hwaddr = parsed[0] // Grab the 'ra' field (1st one) > ip4addr = lookup_hwaddr_in_arp(hwaddr) > <do something with ip4addr> > n++; > } > > Dan Williams wrote: >> 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. >> > > So, like michail said, do something like: > > n = 0 > while (True) { > buf = output of (iwpriv msh0 fwt_list_neigh n) > if (buf == "(null)") > break; // all done > > <parse buf into fields> > hwaddr = parsed[0] // Grab the 'ra' field (1st one) > ip4addr = lookup_hwaddr_in_arp(hwaddr) > <do something with ip4addr> > n++; > } > > Look on the 'olpc' branch of the libertas driver here: > > http://git.infradead.org/?p=libertas-2.6.git;a=blob;f=drivers/net/wireless/libertas/README;hb=olpc > http://git.infradead.org/?p=libertas-2.6.git;a=blob;f=drivers/net/wireless/libertas/ioctl.c;hb=olpc > > The README has a description of the command, and the ioctl.c has the > implementation. Just search for the string "neigh" and you'll find it. > > Dan > > >>>> Basically aside from the vserver bits, which no one has seen, I don't >>>> see a particular advantage to using rsync. In fact, I see serious >>>> downsides since it misses some of the key critical advantages of using >>>> our own tool not the least of which is that we can make our tool do what >>>> we want and with rsync you're talking about changing the protocols. >>>> >>>> >>> 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. 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). >> >> >> _______________________________________________ >> Devel mailing list >> [email protected] >> http://lists.laptop.org/listinfo/devel >> > > _______________________________________________ > Devel mailing list > [email protected] > http://lists.laptop.org/listinfo/devel > _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
