1 / 11

*Towards A Common API for Structured Peer-to-Peer Overlays

This study explores the concept of a common API for structured peer-to-peer overlays, focusing on key-based routing and its application in decentralized systems.

lwoodruff
Download Presentation

*Towards A Common API for Structured Peer-to-Peer Overlays

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. *Towards A Common API for Structured Peer-to-Peer Overlays Frank Dabek, Ben Y. Zhao,Peter Druschel, John Kubiatowicz, Ion Stoica MIT, U. C. Berkeley, and Rice * Conducted under the IRIS project (NSF)

  2. State of the Art • Lots and lots of peer to peer applications • Decentralized file systems, archival backup • Group communication / coordination • Routing layers for anonymity, attack resilience • Scalable content distribution • Built on scalable, self-organizing overlays • E.g. CAN, Chord, Pastry, Tapestry, Kademlia, etc… • Semantic differences • Store/get data, locate objects, multicast / anycast • How do these functional layers relate? • What is the smallest common denominator? IPTPS 2003 ravenben@eecs.berkeley.edu

  3. Some Abstractions • Distributed Hash Tables (DHT) • Simple store and retrieve of values with a key • Values can be of any type • Decentralized Object Location and Routing (DOLR) • Decentralized directory service for endpoints/objects • Route messages to nearest available endpoint • Multicast / Anycast (CAST) • Scalable group communication • Decentralized membership management IPTPS 2003 ravenben@eecs.berkeley.edu

  4. Tier 1 Interfaces IPTPS 2003 ravenben@eecs.berkeley.edu

  5. Structured P2P Overlays CFS PAST i3 SplitStream Bayeux OceanStore Tier 2 Tier 1 DHT CAST DOLR Key-based Routing Tier 0 IPTPS 2003 ravenben@eecs.berkeley.edu

  6. The Common Denominator • Key-based Routing layer (Tier 0) • Large sparse Id space N(160 bits: 0 – 2160 represented as base b) • Nodes in overlay network have nodeIds  N • Given k  N, overlay deterministically maps kto its root node (a live node in the network) • Goal: Standardize API at this layer • Main routing call • route (key, msg, [node]) • Route message to node currently responsible for key • Supplementary calls • Flexible upcall interface for customized routing • Accessing and managing the ID-space IPTPS 2003 ravenben@eecs.berkeley.edu

  7. Application Application forward deliver msg msg msg KBR Layer KBR Layer Flexible Routing via Upcalls • Deliver(key, msg) • Delivers a message to application at the destination • Forward(&key, &msg, &nextHopNode) • Synchronous upcall with normal next hop node • Applications can override messages • Update(node, boolean joined) • Upcall invoked to inform application of a node joining or leaving the local node’s neighborSet IPTPS 2003 ravenben@eecs.berkeley.edu

  8. KBR API (managing ID space) • Expose local routing table • nextHopSet = local_lookup (key, num, safe) • Query the ID space • nodehandle[ ] = neighborSet (max_rank) • nodehandle[ ] = replicaSet (key, num) • boolean = range (node, rank, lkey, rkey) IPTPS 2003 ravenben@eecs.berkeley.edu

  9. Caching DHT Illustrated IPTPS 2003 ravenben@eecs.berkeley.edu

  10. Caching DHT Implementation • Interface • put (key, value) • value = get (key) • Implementation (source S, client C, root R) • Put: route(key, [PUT,value,S])Forward upcall: store valueDeliver upcall: store value • Get: route(key, [GET,C])Forward upcall: if cached, route(C, [value]), FINDeliver upcall: if found, route(C, [value]) IPTPS 2003 ravenben@eecs.berkeley.edu

  11. Ongoing Work • What’s next • Better understanding of DOLR vs. CAST • Decentralized endpoint management • Policies in placement of indirection points • APIs and semantics for Tier 1: (DHT/DOLR/CAST) • KBR API implementation in current protocols • See paper for additional details • Implementation of Tier 1 interfaces on KBR • KBR API support on selected P2P systems IPTPS 2003 ravenben@eecs.berkeley.edu

More Related