Ticket #5078 (new defect)
A more mesh-friendly presence protocol for salut
| Reported by: | sjoerd | Owned by: | sjoerd |
|---|---|---|---|
| Priority: | normal | Milestone: | Opportunity |
| Component: | telepathy-salut | Version: | |
| Keywords: | Cc: | ypod@…, daf, gdesmott, morgs, cjb | |
| Action Needed: | Verified: | no | |
| Blocked By: | Blocking: |
Description
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:
- Know who is on the mesh (and who left!).. With updates as fast as possible (Say within 30 seconds)
- 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):
- Have some idea of where a node is in the network
- 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
