System update spec proposal

[Polychronis Ypodimatopoulos]

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