Tapestry

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 gt 42 gt 42A gt 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 Phils Books (Og 4378)

13
Locating Objects I

• Client sends message towards objects 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 objects
  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 Ns presence
• Update pointers to objects for which N becomes
  the new root
• Have N build its routing table

16
Node Insertion II

• Ns 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 Ns 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