On Jan 9, 2008, at 2:55 PM, Michail Bletsas wrote: > David Woodhouse <[EMAIL PROTECTED]> wrote on 01/09/2008 02:40:46 PM: > > >> We can also >> check the mesh path length to the origin of each RA we see, and >> choose >> the best one. >> > > The way this was originally implemented in a way that can be used > for any > "well defined" service (not just network gateways), > was to assign an anycast MAC address to such well defined services. > > So when a node is looking to see if there is another node providing > such a > service in the mesh, all that it has to do is a path discovery for > the MAC > address corresponding to that service. If the path discovery is > successful, both the presence of the service as well as the optimal > path > to it has been discovered. > > In the case of the mesh portal (A NAT Internet Gateway in our case) we > need to get back the IP address of the gateway as well as DNS info. > A simple python server listening at a predefined port was providing > that. > That simple server has been replaced by a complete DHCP server in our > current implementation.
The DHCP server was needed anyway. And to implement shortest path routing both for sent and received packets, we needed a mechanism for receiving an IP address that reflected the nearest MPP anyway (or use NAT, something we would like to avoid inside the school....) wad _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
