Chord is a distributed lookup system that maps keys to nodes in a peer-to-peer network. It uses consistent hashing to assign keys and nodes to identifiers arranged in a ring. Each node maintains a finger table to efficiently route queries to the successor node storing a given key in O(logN) hops. When nodes join or leave, they update their own and successor nodes' finger tables and notify layers above to move any stored keys. This allows Chord to dynamically adapt to changes while continuing to efficiently lookup stored data.

1. Chord: A scalable peer-to-peer lookup service for
internet applications
Tom Faulhaber
tom@infolace.com
Papers We Love SF
August 2016

3. Chord is a completely peer-to-peer distributed key management
system that works under dynamic membership churn.

4. Context

7. Idea 1: Consistent Hashing

8. Consistent Hashing
• Map keys to a hash m-bits
long, e.g. SHA-1.
• Construct a ring with
operations performed mod 2m

9. Consistent Hashing
• Map keys to a hash m-bits
long, e.g. SHA-1.
• Construct a ring with
operations performed
• For example, take
• Gives us separate
addresses.
m = 3
23
= 8
mod 2m

10. Nodes and Keys
• Each node in the network has
an address, typically
• We define , the
successor of , defined as
• Key is stored at node
• Each node knows
• gives lookup
performance, where is the
number of nodes
addr = hash(ip)
succ(k)
min(n) | n k mod 2m
succ(k) O(N)
N
k succ(k)
k
n
n0
= succ(n + 1 mod 2m
)

11. Idea 2: Finger Tables

12. Finger tables
• To move from to
Chord uses a “finger table” to
track nodes around the ring.
• Fundamental insight
- dense information nearby,
- sparse information far away
• Table defined by:
• Also track
O(n) O(log n)
finger[k].start = (n + 2k 1
) mod 2m
, 1  k  m
.interval = [finger[k].start, finger[k + 1].start)
.node = succ(finger[k].start)
successor = finger[1].node
predecessor

13. Example Layout
m = 6
2m
= 64
Node Location
α 7
β 16
γ 42
δ 44
ε 50
ζ 52
η 3
θ 4
This table does not exist!

14. The View from α
k start end n
1 8 8 β
2 9 10 β
3 11 14 β
4 15 22 β
5 23 38 γ
6 39 7 γ
Starting from α, retrieve key 51
First step, ask γ

15. The View from γ
k start end n
1 43 43 δ
2 44 45 δ
3 46 49 ε
4 50 57 ε
5 58 9 η
6 10 42 β
Second step, ask ε

16. The View from ε
k start end n
1 51 51 ζ
2 52 53 ζ
3 54 57 η
4 58 1 η
5 2 17 η
6 18 50 γ
Third step, ask ζ
At this point, so ζ
will have the key
succ(51) = ⇣

17. Idea 3: Handling Churn

18. Joining the network
Once a node has assigned itself
an id, , it does 3 things:
1. Builds its finger table and
predecessor
n0
k start n
1
2
3
4
5
… … …
n0
+ 1 succ(n0
+ 1)
n0
+ 2
n0
+ 4
n0
+ 8
n0
+ 16 succ(n0
+ 16)
succ(n0
+ 2)
succ(n0
+ 4)
succ(n0
+ 8)

19. Joining the network
Once a node has assigned itself
an id, , it does 3 things:
1. Builds its finger table and
predecessor
2. Updates other nodes that
should have their finger tables
point to
3. Notify upper layers of
software that they need to
move keys.
n0
n0

20. Joining the network
Once a node has assigned itself
an id, , it does 3 things:
1. Builds its finger table and
predecessor
2. Updates other nodes that
should have their finger tables
point to
3. Notify upper layers of
software that they need to
move keys.
n0
n0
Joins take messages
keys will be moved
O(log2
n)
O(
1
N
)

21. Concurrency & Failure
Two basic mechanisms:
1. Every node periodically performs stabilization
2. Each node maintains a successor list rather than a single successor
When a node fails, it’s keys are lost. Other mechanisms are used by higher
levels to build resiliency, e.g. republishing or replication.

22. Related Work

23. Related Work
• Pastry
• CAN
• Kademlia
• Tapestry

24. Impact

25. Impact
• Research applications in domains such as distributed file systems, pub-sub,
document sharing, search algorithms.
• Basis for sharing data to nodes in systems like Cassandra without requiring a
global index.

26. The End!