1 / 40

Chord: A Scalable Peer-to-Peer Lookup Protocol for Internet Applications

Explore the Chord protocol by Stoica et al., a solution for decentralized peer-to-peer applications. Learn about key mapping, finger tables, key location, and more for efficient data retrieval and load balancing.

bessiem
Download Presentation

Chord: A Scalable Peer-to-Peer Lookup Protocol for Internet Applications

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. Chord: A Scalable Peer-to-Peer Lookup Protocol for Internet Applications Stoica et al. Presented by Tam Chantem March 30, 2007

  2. Outline • Problem • Approach • Results • Conclusion Chord: Stoica et al.

  3. Peer-to-Peer Applications • More and more popular • Decentralized • Information is everywhere Chord: Stoica et al.

  4. Peer-to-Peer Applications • More and more popular • Decentralized • Information is everywhere • How to find data? Chord: Stoica et al.

  5. Peer-to-Peer Applications • More and more popular • Decentralized • Information is everywhere • How to find data? • As nodes come and go… Chord: Stoica et al.

  6. Some Solutions • Exhaustive search • Centralized directory servers Chord: Stoica et al.

  7. Some Solutions • Exhaustive search • Centralized directory servers Not Scalable Chord: Stoica et al.

  8. Some Solutions • Exhaustive search • Centralized directory servers • Partial search • Caching Not Scalable Chord: Stoica et al.

  9. Some Solutions • Exhaustive search • Centralized directory servers • Partial search • Caching Not Scalable False negative, Inconsistency Chord: Stoica et al.

  10. Chord • Distributed hash table across nodes • Given a key, map key to node storing the data • Flat naming for keys and nodes Chord: Stoica et al.

  11. Using Chord 3. Contact 292.164.2.3 Application A 1. Lookup(key) 2. IP = 292.164.2.3 Chord Node i Chord: Stoica et al.

  12. Hashing in Chord • Consistent hash function: m-bit IDs • Hash key  key ID • Hash node’s IP address  node ID • Use hashing to map key ID to node ID Chord: Stoica et al.

  13. Chord Ring • Organize nodes based on their ID N56 N8 N14 N42 N32 N38 Chord: Stoica et al.

  14. Key Mapping • Key k  First node n, n’s ID  k • Balance load with high probability Chord: Stoica et al.

  15. Key Mapping Example N56 N8 K54 K10 N14 N42 K38 N38 K24 N32 K30 Chord: Stoica et al.

  16. Key Location • Linear time if nodes keep track of one successor • Keep track of more successors to get logarithmic time • m successors if ID is m-bit long • Use finger table Chord: Stoica et al.

  17. Finger Table • Want to reduce distance from node that makes query to target node by half each time • The ith entry of the table of n is node that succeeds n by at least 2i-1 nodes finger[i] = successor(n + 2i-1) % m Chord: Stoica et al.

  18. Constructing a Finger Table • We don’t know whether a node exists Chord: Stoica et al.

  19. Constructing a Finger Table • We don’t know whether a node exists • So to fill an entry: • Compute: key = successor(n + 2i-1) % m • Do lookup(key) • Fill entry with the node that has key Chord: Stoica et al.

  20. Constructing a Finger Table • We don’t know whether a node exists • So to fill an entry: • Compute: key = successor(n + 2i-1) % m • Do lookup(key) • Fill entry with the node that has key • Also keep track of predecessor Chord: Stoica et al.

  21. Locating a Key • Go to largest node that precedes key Chord: Stoica et al.

  22. Looking up K54 by N8 N56 N8 K10 K54 N14 N42 K38 N38 K24 N32 K30 Chord: Stoica et al.

  23. Looking up K54 by N8 N56 N8 K10 K54 N14 N42 K38 N38 K24 N32 K30 Chord: Stoica et al.

  24. Looking up K54 by N8 N56 N8 K10 K54 N14 N42 K38 N38 K24 N32 K30 Chord: Stoica et al.

  25. Accounting for Volatility • Node relies on successor(s) for correctness • How can we ensure this when nodes leave/join the network? Chord: Stoica et al.

  26. Key Remapping N56 N8 K54 K10 N14 N42 K38 N38 K24 N32 K30 Chord: Stoica et al.

  27. Key Remapping N56 N8 K54 K10 N14 N42 K38 N38 K24 N32 K30 Chord: Stoica et al.

  28. Key Remapping N56 N8 K54 K10 N14 N42 N38 K24 N32 K30 Chord: Stoica et al.

  29. Joining New Node N56 N8 K54 N14 N42 K10 K38 N38 K24 N32 K30 Chord: Stoica et al.

  30. Joining New Node N56 N8 K54 Requests N14 N42 K10 K38 N38 K24 N32 K30 Chord: Stoica et al.

  31. Joining New Node N56 N8 K54 Successor info N14 N42 K10 K38 N38 K24 N32 K30 Chord: Stoica et al.

  32. Joining N56 N8 K54 N14 N42 K10 K38 N38 N32 N26 K24 K30 Chord: Stoica et al.

  33. Joining N56 N8 K54 N14 N42 K10 K38 N38 K24 N32 N26 K30 Chord: Stoica et al.

  34. Periodic Stabilizing N56 N8 K54 predecessor? N14 N42 K10 K38 N38 K24 N32 N26 K30 Chord: Stoica et al.

  35. Periodic Stabilizing N56 N8 K54 N14 N26 N42 K10 K38 N38 K24 N32 N26 K30 Chord: Stoica et al.

  36. Periodic Stabilizing N56 N8 K54 N14 N42 K10 K38 N38 N26 K24 N32 K30 Chord: Stoica et al.

  37. Hard Cases • Data may not be found while pointers are being moved • In reality, may not have time for stabilization Chord: Stoica et al.

  38. Performance • Good load balancing • Logarithmic path length for lookups • ~0.15% of lookups fail • When join/leave rate is 0.40 per second • Ask incorrect successor Chord: Stoica et al.

  39. Chord • Locate distributed data based on key • Features: • Load balancing • High availability • Scalability Chord: Stoica et al.

  40. Discussion • Strengths and weaknesses of Chord? • How can we improve Chord? • Chord instead of DNS? Chord: Stoica et al.

More Related