#5078 NORM Opportu: A more mesh-friendly presence protocol for salut

[Zarro Boogs per Child]

#5078: A more mesh-friendly presence protocol for salut
-----------------------------+----------------------------------------------
 Reporter:  sjoerd           |       Owner:  sjoerd     
     Type:  defect           |      Status:  new        
 Priority:  normal           |   Milestone:  Opportunity
Component:  telepathy-salut  |     Version:             
 Keywords:                   |    Verified:  0          
-----------------------------+----------------------------------------------
 Salut uses mdns for presence. Which works quite nice and is standardized.
 But it's not very good for a mesh network. Especially since in most of the
 olpc use-cases, each node needs essentially the same information some
 quite nice enhancements could be made.

 Now I've been thinking a lot lately about what we could do to
 improve presence on salut. Basically the requirements are:
  0. Know who is on the mesh (and who left!).. With updates as fast
     as possible (Say within 30 seconds)
  1. Get some metadata about the nodes. Most of which doesn't change
     or doesn't change often (nick, color, jid, key, etc). And some
     of which can change on a regular basis (current activity of
     someone).

 And some of the things that would be very nice to have, but not critical
 (i.e. things we don't have now):
   2. Have some idea of where a node is in the network
   3. Have some estimate of the latency and quality of the path to
      a node.



 When i was in Boston in october we discussed Polychronis' presence
 protocol which fits most of the requirements (except 1).

 For 1, it's nice to observer that the info you want is of interest too all
 nodes . So instead of needing to ask the node about it's own metadata, you
 can just ask your neighbours.. And if they don't know they can ask their
 neighbours etc. Also when a node changes its info, it should just pass it
 on to its neighbours, and they can pass it on to theirs etc etc, so
 information can be essentially pushed into the network instead of the need
 of polling all the time.

 All this sounds great. But there is one major problem. To work all nodes
 on the network need to take part in this. Ideally nodes in
 an OLPC mesh are suspended most of the time. Unfortunately for this
 protocol to work, you every node in the network to take part in it all the
 time.. Which makes it conflict with saving as much power as possible..
 Unless we could have the cooperation of the wireless chip, unfortunately
 as the firmware isn't open this is a bit hard. (See #46 and #429)

 Actually (depending on the exact capabilities of the chipset).. Having the
 ability to offload things to wireless could help a lot for Clique too. If
 an activity is idle, all it basically does is sending out keep-alive and
 session messages to ensure that the group is in sync.. All this could be
 done by the wireless card, allowing the host to sleep untill something
 actually interesting happens

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