210 likes | 647 Views
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
E N D
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, NID • Each endpoint is randomly assigned a GUID, OG, from the same ID space • Chosen randomly from same ID space • Typical ID space is SHA-1 (160 bits) • An optional application ID (Aid) is used to select an appropriate process on each node for delivery
DOLR networking API • Four operations provided in a Tapestry API: • PublishObject(Og, Aid): Publish object Og on the local node • UnpublishObject(Og, Aid): Remove location mappings for object Og. • RouteToObject(Og, Aid): Route a message to node where Og is stored • RouteToNode(NID, Aid, Exact): Route a message to node NID. 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 Illustration • Routing table for node 4227
Message Routing I • Every object ID is mapped to a root node • The root node of object Og is the node with NID = Og (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 (Og = 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 Og 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