1. Tapestry An off-the-wall routing protocol? Presented by Peter, Erik, and Morten

2. Overview What is Tapestry? Terminology A Tapestry networking API Message routing Object publishing Object locating Node insertion & deletion

3. What is Tapestry? Peer-to-peer routing protocol Provides Decentralized Object Location and Routing (DOLR)  Routes messages to endpoints using key-based routing  Endpoints can be both nodes and objects Operations succeed nearly 100% of the time, even under extreme network conditions

4. Terminology Nodes and objects Each node is randomly assigned a node ID, N ID Each endpoint is randomly assigned a GUID, O G, from the same ID space Chosen randomly from same ID space Typical ID space is SHA-1 (160 bits) An optional application ID (A id ) is used to select an appropriate process on each node for delivery

5. DOLR networking API Four operations provided in a Tapestry API:  PublishObject(O g, A id ): Publish object O g on the local node  UnpublishObject( O g, A id ): Remove location mappings for object O g.  RouteToObject( O g, A id ): Route a message to node where O g is stored  RouteToNode( N ID, A id, Exact): Route a message to node N ID. Exact determines whether a ”close match” is sufficient for delivery

6. Node Characteristics Each node stores a routing table  Each level stores neighbors that match a prefix up to a certain position in the ID  If there is a hole in the routing table, there is no such node in the network For redundancy, backup neighbor links are stored Each node also stores backpointers that point to nodes that point to it

7. Routing Table Example Node 5230 01234567 L1 01661234277130074001X60667772 L2 50345121X53975449551856715739 L3 520352175228X5246525452685271 L4 X5231523252335234523552365237

8. Routing Table Illustration Routing table for node 4227

9. Message Routing I Every object ID is mapped to a root node The root node of object O g is the node with N ID = O g (or closest match) Uses prefix routing  Lookup for 42AD: 4*** => 42** => 42A* => 42AD In case of an empty neighbour entry, use surrogate routing  Route to the next highest (if no entry for 42**, try 43**)

10. Message Routing II Routing message from node 5230 to 42AD

11. Publishing Objects I A node sends a publish message towards the root node of the object. At each hop, nodes store pointers to the source node  Data remains at source. No replication takes place anywhere.  In case of objects stored on multiple servers, pointers are stored in order of network latency Nodes periodically republish objects

12. Publishing Objects II Publishing Phil’s Books ( O g = 4378)

13. Locating Objects I Client sends message towards object’s root node Each hop checks its list of pointers  In case of a match, message is forwarded directly to the node storing the object  Otherwise, message continues towards the object’s root

14. Locating Objects II Locating O g 4378 from 4B4F and 4664

15. Node Insertion I We want to do three things with the new node, N:  Notify all existing nodes of N’s presence  Update pointers to objects for which N becomes the new root  Have N build its routing table

16. Node Insertion II N’s ”root node” multicasts a message to all nodes sharing the same prefix, p. In case N becomes the new root for some objects, pointers are updated to reflect this change during the multicast All nodes contacted during multicast contact N and are added to N’s routing table at level p. Levels p-1, p-2,..., 1 are filled by requesting backpointers from nodes on succeeding level

17. Node Deletion Voluntary node deletion  Node N tells all backpointer nodes of its decision and give each neighbour a replacement node from its own routing table Involuntary node deletion (i.e., network failure)  Redundancy is built-in through backup links in routing tables  Nodes use periodic beacons to detect outgoing link and node failures  Repair process is augmented by periodic republishing of object references