#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:                
 Keywords:  Update.1?         |    Verified:  0             
 Blocking:                    |   Blockedby:                
------------------------------+---------------------------------------------
 Currently the algorithm in presence service starts Salut automatically
 when avahi is available, and then when we get an IPv4 address from Network
 Manager, we start trying to connect with gabble in parallel, and disable
 salut if we succeed at connecting with gabble.

 Salut makes mDNS queries to discover presence records when it;s running.
 Combined with flood-fill multicast, this has the result that the network
 is hugely clogged with mDNS resolution traffic, and actively prohibits
 other users from DHCPing, registering, or connecting to the XMPP server,
 causing them to in turn stay on mDNS, exacerbating the problem further
 still.

 However, given that DHCP on the XOs is modified to unicast to a well known
 "anycast" MAC address on the school server, we can look for this MAC
 address to determine that a school server is present, and we should then
 shut down salut to stop *any* mDNS activity.

 dwmw2 can confirm a way to determine that this MAC address is reachable,
 but it seems to be something along the lines of try and send traffic to it
 somehow, then inspect the mesh routing table to see if it appeared in
 there

 The algorithm would then look more like:

 stop salut
 if we're on mesh, and the school server is reachable by anycast:
   while 1:
     try to connect with gabble
     sleep
 else:
   connect with salut
   while 1:
     try to connect with gabble
     if we succeed:
       stop salut
     else:
       sleep

 We should run this algorithm every time we arrive on a new network, and
 when we resume from sleep.

 We need to decide three timeouts:
  1) start of day: how long do we look for the school server anycast MAC
 before we decide we're OK to enable salut?
  2) kids wander off/server dies: how long after we're disconnected from
 the school server before we decide its OK to enable to salut?
  3) kids wander back/server resurrected: how often do we look for the
 school server anycast address when we're using salut, to decide we should
 switch salut off and wait for gabble to work instead?

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