1 / 26

Tapestry: Finding Nearby Objects in Peer-to-Peer Networks

Tapestry: Finding Nearby Objects in Peer-to-Peer Networks. Joint with: Ling Huang Anthony Joseph Robert Krauthgamer John Kubiatowicz Satish Rao Sean Rhea Jeremy Stribling Ben Zhao. Object Location. Behind the Cloud. Why nearby? (DHT vs. DOLR).

hyde
Download Presentation

Tapestry: Finding Nearby Objects in Peer-to-Peer Networks

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: Finding Nearby Objects in Peer-to-Peer Networks Joint with: Ling Huang Anthony Joseph Robert Krauthgamer John Kubiatowicz Satish Rao Sean Rhea Jeremy Stribling Ben Zhao

  2. Object Location

  3. Behind the Cloud

  4. Why nearby?(DHT vs. DOLR) Nearby= low stretch, ratio of distance traveled to find object to distance to closest copy of object • Objects are services, so distance isn’t one-time cost (see COMPASS) • (smart) publishers put objects at chosen locations in network • Bob Miller places retreat schedule at node in Berkeley • Wildly popular objects

  5. Well-Placed Objects

  6. Popular Objects

  7. Outline • Low stretch dynamic peer-to-peer network • Tolerate failures in network • Adapting to network variation • Future work

  8. Distributed Hash Tables • These systems give • Guaranteed location • Join and leave algorithms • Load-balanced storage • No stretch guarantees

  9. Low Stretch Approaches • Not dynamic Tapestry is first dynamic low-stretch scheme

  10. PRR/Tapestry Country State City

  11. PRR/Tapestry Level 3 Level 2 Level 1 Two object types: red and blue, so two trees

  12. Neighbor Table For “5471” (Octal) NodeID 5416 NodeID 5455 5470 540x 50xx 0xxx 5471 541x 51xx 1xxx 5472 542x 52xx 2xxx 3 3 5473 543x 53xx 3xxx Ø 544x 54xx 4xxx 3 5475 545x 55xx 5xxx NodeID 5432 NodeID 5471 2 Ø 546x 56xx 6xxx 5477 547x 57xx 7xxx 4 4 3 2 1 2 Routing Levels 2 NodeID 5470 NodeID 5061 Balancing Load 1 NodeID 5123

  13. Big Challenge: Joining Nodes Theorem 1 [HKRZ02] When peer A is finished inserting, it knows about all relevant peers that have finished insertion.

  14. Results • Correctness O(log n) insert & delete • Concurrent inserts in a lock-free fashion • Neighbor-search routine • Required to keep lowstretch • All low-stretch schemes do something like this • Zhao, Huang, Stribling, Rhea, Joseph & Kubiatowicz (JSAC) • This works! Implemented algorithms • Measured performance

  15. Neighbor Search In growth-restricted networks (with no additional space!): Theorem 2 [HKRZ02] Can find nearest neighbor with high probability with O(log2 n) messages Theorem 3[HKMR04]Can find nearest neighbor, and messages is O(log n) with high probability

  16. Outline • Low stretch dynamic peer-to-peer network • Tolerate failures in network • Adapting to network variation • Future work

  17. Behind the Cloud Again

  18. Dealing with faults • Multiple paths • Castro et. al • One failure along path, path breaks • Wide path • Paths faulty at the same place to break • Exponential difference in width effect • “retrofit” Tapestry to do latter in slightly malicious networks Failed! Still good…

  19. Effective even for small overhead Theorem 4In growth restricted spaces, can make probability of failed route less than 1/nc for width O(clog n) Hildrum & Kubiatowicz, DISC02

  20. Wide path vs. multiple paths

  21. Outline • Low stretch dynamic peer-to-peer network • Tolerate failures in network • Adapting to Network Variation • Future work

  22. Digit size affects performance

  23. Network not homogeneous • Previous schemes picked a digit size • How do we find a good one? • But what if there isn’t one? Nebraska San Francisco Paris

  24. New Result • Pick digit size based on local measurements • Don’t need to guess • Vary digit size depending on location • No, it’s not obvious that this works, but it does! Hildrum, Krauthgamer & Kubiatowicz [SPAA04]: Dynamic, locally optimal low-stretch network

  25. Conclusions and Future Work Conclusion • Low stretch object location is practical • System provably good [HKRZ02] • System built [ZHSJK] Open Questions • Do we need a DOLR? • Object placement schemes? Workload? • Examples where low stretch, load balance, and low storage not possible simultaneously • What is tradeoff between degree, stretch, load balance as function of graph? • Can we get best possible? Trade off smoothly?

  26. Tapestry People • Ling Huang • Anthony Joseph • John Kubiatowicz • Sean Rhea • Jeremy Stribling • Ben Zhao • and…OceanStore group members

More Related