1 / 30

YAPPERS: A Peer-to-Peer Lookup Service over Arbitrary Topology

YAPPERS: A Peer-to-Peer Lookup Service over Arbitrary Topology. Qixiang Sun Prasanna Ganesan Hector Garcia-Molina Stanford University. Outline. Background and Motivation High-level overview of YAPPERS Brief evaluation. Where is X?. Problem. A. C. B. Problem (2). 1. Search.

aolani
Download Presentation

YAPPERS: A Peer-to-Peer Lookup Service over Arbitrary Topology

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. YAPPERS: A Peer-to-Peer Lookup Service over Arbitrary Topology Qixiang Sun Prasanna Ganesan Hector Garcia-Molina Stanford University

  2. Outline • Background and Motivation • High-level overview of YAPPERS • Brief evaluation

  3. Where is X? Problem

  4. A C B Problem (2) 1. Search 2. Node join/leave 3. Register/remove content

  5. Gnutella-style join anywhere in the overlay register do nothing search flood the overlay Background

  6. Distributed hash table (DHT) join a unique location in the overlay register place pointer at a unique node search route towards the unique node Background (2) Chord . . . CAN

  7. Gnutella-style Simple Local control Robust Arbitrary topology Inefficient Disturbs many nodes DHT Efficient search Restricted overlay Difficulty with dynamism Background (3)

  8. Motivation • Best of both worlds • Gnutella’s local interactions • DHT-like efficiency • Respect application-defined topology • Social network • Ad hoc wireless network • Physical-network proximity

  9. Partition Nodes Given any overlay, first partition nodes into buckets (colors) based on hash of IP

  10. Partition Nodes Given any overlay, first partition nodes into buckets (colors) based on hash of IP

  11. Partition Nodes (2) Around each node, there is at least one node of each color X Y May require backup color assignments

  12. register yellow content at a yellow node Register Content Partition content space into buckets (colors) and register pointer at “nearby” nodes. Nodes around Z form a small hash table! Z register red content locally

  13. Searching Content Start at a “nearby” colored node, search other nodes of the same color. W X Y U V Z

  14. Searching Content (2) A smaller overlay for each color and use Gnutella-style flood Fan-out = degree of nodes in the smaller overlay

  15. Recap • Hybrid approach • Around each node, act like a hash table • Flood the relevant nodes in the entire network • What do we gain? • Respect original overlay • Efficient search for popular data • Avoid disturbing nodes unnecessarily

  16. Brief Evaluation • Using a 24,702 nodes Gnutella snapshot as the underlying overlay • We study • Number of nodes contacted per query when searching the entire network • Trade-off in using our hybrid approach when flooding the entire network

  17. Limited by the number of nodes “nearby” Nodes Searched per Query

  18. Trade-off • Fan-out = degree of each colored node when flooding “nearby” nodes of the same color • Good in searching nearby nodes quickly. • Bad in searching the entire network

  19. Conclusion Does YAPPERS work? • YES • Respects the original overlay • Searches efficiently in small area • Disturbs fewer nodes than Gnutella • Handles node arrival/departure better than DHT • NO • Large fan-out (vanilla flooding won’t work)

  20. For More Information • A short position paper advocating locally-organized P2P systems http://dbpubs.stanford.edu/pub/2002-60 • Other P2P work at Stanford http://www-db.stanford.edu/peers

  21. Recap • node join • anywhere in the overlay • register content • at nearby node(s) of the appropriate color • search • start at a nearby node of the search color and then flood nodes of the same color.

  22. What Do We Gain? • Respect original overlay • Efficient search for popular data • Avoid disturbing nodes unnecessarily • Better handling of dynamic node arrival and departure

  23. Design Issues • How to build a small hash table around each node, i.e., assign colors? • How to connect nodes of the same color?

  24. C X A B Small-scale Hash Table Small = all nodes within h hops (e.g., h=2) • Consistent across overlapping hash tables • Stable when nodes enter/leave

  25. Small-scale Hash Table (2) • Fixed number of buckets (colors) • Determine bucket (color) based on the hash value of node IP addresses • Multiple nodes of the same color • No nodes of a color

  26. Frontier Node B All nodes within h hops A C Need to track all nodes within 2h+1 hops Searching the Overlay Find another node of the same color in a “nearby” hash table

  27. Searching the Overlay (2) For a color C and each frontier node v, 1. determine which nodes v might contact to search for color C 2. contact these nodes Theorem: Regardless of starting node, one can search all nodes of all color.

  28. 3.7 = 11.5% 32 Buckets per Node • Using 32 buckets (colors) per hash table AVG = 3.7

  29. X A Overloading a Node • A node may have many colors even if it has a large neighborhood.

More Related