#6299 HIGH Never A: presence service should disable salut in the presence of school servers on mesh

[Zarro Boogs per Child]

#6299: presence service should disable salut in the presence of school servers on
mesh
-------------------------------+--------------------------------------------
  Reporter:  robot101          |       Owner:  Collabora     
      Type:  defect            |      Status:  new           
  Priority:  high              |   Milestone:  Never Assigned
 Component:  presence-service  |     Version:                
Resolution:                    |    Keywords:  Update.1?     
  Verified:  0                 |    Blocking:                
 Blockedby:                    |  
-------------------------------+--------------------------------------------

Comment(by mbletsas):

 Replying to gdesmott:

     First, I need to know more about this anycast address.

 The anycast address is there to provide a mechanism to select the instance
 of a "standard" service that is "closer" (is accessible via the lowest
 cost path) to the mesh node looking for that service.

 The idea is that all "standard" XO services (the only one currently in use
 is MPP) listen to a predefined anycast address. So when a node needs to
 find if there is an instance of the required service running on the mesh,
 just tries to contact that service at the predefined anycast address.

 How this can be done, is still a matter of programming convenience at this
 point. In the original implementation of the idea, we had all MPPs run a
 small daemon at a predefined IP. Then at the nodes looking for the MPP, we
 had a static ARP mapping between the predefined MAC address and the
 predefined IP. Thus, a simple ping to the predefined IP would reveal a)
 whether there is an MPP on the network and b) discover the lowest cost
 path to it (if there was more than one).

 Then contacting a simple python server listening on the predefined IP,
 would reveal the real IP address of the MPP as well as the DNS server
 info.

 To do the same with the current incarnation of the school server MPP or XO
 MPP (they differ in that the former assigns the IP address via DHCP where
 the later only serves GW and DNS info), we send the DHCP request to the
 anycast MAC address (as opposed to the broadcast one. In that manner, we
 ensure that it is the "closest" MPP that responds.

 The same principle is applicable to every "standard" service that mesh
 nodes might want to offer to their peers. The presence services and its
 future ad-hoc supernodes are a prime example.

 The original idea was to use just one anycast address and then return the
 higher level information via a "portmapper/rpc" type of info server
 running on the machine.

 It doesn't take much thinking to see the obvious issues with that approach
 (multiple step process, lots of traffic), so the idea to have a range of
 configurable MAC addresses that are statically mapped to pre-defined
 services (that the node might be listening to, beyond its own address the
 standard multicast/broadcast addresses) was adopted.

 The way to set which of those anycast addresses are active is described in
 this post:

     * Support for anycast addresses mask (
 http://lists.infradead.org/pipermail/libertas-dev/2007-June/000404.html )

 M

-- 
Ticket URL: <http://dev.laptop.org/ticket/6299#comment:6>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system