Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications

Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek and Hari alakrishnan

MIT Laboratory for CS

SIGCOMM Proceedings, 2001

http://pdos.lcs.mit.edu/chord/

Chord Contribution Chord is a scalable protocol for

lookup in a dynamic peer-to-peer system with frequent node arrivals and departures.

Peer-to-peer Application Characteristics

Direct connection, without a central point of management

Large scale Concurrent node join Concurrent node leave

The Lookup Problem

Internet

N1

N2 N3

N6N5

N4

Publisher

Key=“Ma Yo-yo”Value= Sonata…

ClientLookup(“Ma Yo-yo”)

?

Some Approaches Napster (DNS) - centralized Gnutella - flooded Freenet, Chord - decentralized

Centralized lookup (Napster)

Simple Least info maintained in each node A single point of failure

DB server

N1 N2 N3

N6N5

N4

Key=“Ma Yo-yo”Value= Sonata…

Client

2. Lookup(“Ma Yo-yo”)

N7

1. Register “Ma Yo-yo”

3. Here (“Ma Yo-yo”, N7)

4. Download

Flooded queries (Gnutella) Robust Maintain neighbor state in each node Flooded messages over the network

N2

N7 Client

N4

N8

N5N6

N3

N1

Key=“Ma Yo-yo”Value=Sonata…

Lookup(“Ma Yo-yo”)

Here(“Ma Yo-yo”, N7)

Routed queries (Freenet, Chord) Decentralized Maintain route info in each node Scalable

N7

Client

N4 N5N6

N3

N2N1

Lookup(“Ma Yo-yo”)

Key=“Ma Yo-yo”Value=Sonata…

Here (“Ma Yo-yo”, N7)

Chord Basic protocol Node Joins Stabilization Failures and Replication

Chord Properties Assumption: no malicious participants Efficiency: O(log(N)) messages per lookup

N is the total number of servers Scalability: O(log(N)) state per node Robustness: survives massive failures Load balanced: spreading keys evenly

Basic Protocol Main operation

Given a key, maps the key onto a node

Consistent hashing Key identifier = SHA-1(title) Node identifier = SHA-1(IP) Find successor(Key) map key IDs to node IDs

Consistent Hashing [Karger 97] Target: web page caching Like normal hashing, assigns items to

buckets so that each bucket receives roughly the same number of items

Unlike normal hashing, a small change in the bucket set does not induce a total remapping of items to buckets

Consistent Hashing

ID: 2^7 = 128

N32

N90

N105

K80

K20

K5

Circular 7-bitID space

Key 5Key 105

A key is stored at its successor:node with next higher ID

Basic Lookup Inefficient, O(N)

N32

N90

N105

N60

N10N120

K80

“Where is key 80?”

“N90 has K80”

Finger Table (1) Speed up the lookup A routing table with m entries - fingers

At node n, i th entry of its finger tables = successor (n+2^(i-1)), 1≦i≦m

At node n, each finger of its finger table points to the successor of [(n+2^(i-1)) mod (2^m)]

Allows log(N) - time lookups

S=(1+(2^(2-1))) mod (2^3) = 3

S=(1+(2^(1-1))) mod (2^3) = 2

S=(1+(2^(3-1))) mod (2^3) = 5

Lookups take O(log(N)) hops

N32

N10

N5

N20N110

N99

N80

N60

Lookup(K19)

K19

Node Join (1)

N36

N40

N25

1. Lookup(36)K30K38

Node Join (2)

N36

N40

N25

2. N36 sets its ownsuccessor pointer

K30K38

Node Join (3)

N36

N40

N25

3. Copy keys 26..36from N40 to N36

K30K38

K30

Node Join (4)

N36

N40

N25

4. Set N25’s successorpointer

Update finger pointers in the backgroundCorrect successors produce correct lookups

K30K38

K30

Stabilization Stabilization algorithm periodically

verifies and refreshes node knowledge Successor pointers Predecessor pointers Finger tables

Failures and Replication Maintain correct successor pointers

N80 doesn’t know correct successor, so incorrect lookup

N120

N113

N102

N80

N85

N10

Lookup(90)

Solution: successor lists Each node knows r immediate

successors After failure, will know first live

successor Correct successors guarantee

correct lookups

Path length as a function of network size

Failed Lookups versus Node Fail/Join Rate

Chord Summary Chord provides peer-to-peer hash looku

p Efficient: O(log(n)) messages per lookup Robust as nodes fail and join Not deal with malicious users http://pdos.lcs.mit.edu/chord/