1 / 17

Tapestry

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

may-ryan
Télécharger la présentation

Tapestry

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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, 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

  5. 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

  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

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

  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 (Og = 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 Og 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

More Related