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

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

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

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

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

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

Routing Table Example Node L X L X L X L4 X

Routing Table Illustration Routing table for node 4227

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**)

Message Routing II Routing message from node 5230 to 42AD

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

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

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

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

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

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

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