Chord: A Scalable Peer-to-Peer Lookup Protocol for Internet Applications
Stoica et al.
Presented by Tam Chantem
March 30, 2007
03/30/07 Chord: Stoica et al. 3
Peer-to-Peer Applications
• More and more popular
• Decentralized
• Information is everywhere
03/30/07 Chord: Stoica et al. 4
Peer-to-Peer Applications
• More and more popular
• Decentralized
• Information is everywhere– How to find data?
03/30/07 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…
03/30/07 Chord: Stoica et al. 7
Some Solutions
• Exhaustive search
• Centralized directory servers
Not Scalable
03/30/07 Chord: Stoica et al. 8
Some Solutions
• Exhaustive search
• Centralized directory servers
• Partial search
• Caching
Not Scalable
03/30/07 Chord: Stoica et al. 9
Some Solutions
• Exhaustive search
• Centralized directory servers
• Partial search
• Caching
Not Scalable
False negative, Inconsistency
03/30/07 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
03/30/07 Chord: Stoica et al. 11
Using Chord
Application A
Chord
1. Lookup(key) 2. IP = 292.164.2.3
3. Contact 292.164.2.3
Node i
03/30/07 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
03/30/07 Chord: Stoica et al. 13
Chord Ring
• Organize nodes based on their ID
N8
N14
N32N38
N42
N56
03/30/07 Chord: Stoica et al. 14
Key Mapping
• Key k First node n, n’s ID k
• Balance load with high probability
03/30/07 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
03/30/07 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
03/30/07 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
03/30/07 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
03/30/07 Chord: Stoica et al. 21
Locating a Key
• Go to largest node that precedes key
N8 + 1 N14
N8 + 2 N14
N8 + 4 N14
N8 + 8 N32
N8 + 16 N32
N8 + 32 N42
03/30/07 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?
03/30/07 Chord: Stoica et al. 30
Joining
N8
N14
N32
N38
N42
N56
K54
K38
K10
K24
K30
New Node
Requests
03/30/07 Chord: Stoica et al. 31
Joining
N8
N14
N32
N38
N42
N56
K54
K38
K10
K24
K30
New Node
Successor info
03/30/07 Chord: Stoica et al. 34
Periodic Stabilizing
N8
N14
N32
N38
N42
N56
K54
K38
K10
K30
N26
predecessor?
K24
03/30/07 Chord: Stoica et al. 35
Periodic Stabilizing
N8
N14
N32
N38
N42
N56
K54
K38
K10
K30
N26
N26K24
03/30/07 Chord: Stoica et al. 36
Periodic Stabilizing
N8
N14
N32
N38
N42
N56
K54
K38
K10
K24
K30
N26
03/30/07 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
03/30/07 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
03/30/07 Chord: Stoica et al. 39
Chord
• Locate distributed data based on key
• Features:– Load balancing– High availability– Scalability