chord: a peer-to-peer lookup service chord: a peer-to-peer lookup service ion stoicarobert morris...
TRANSCRIPT
CHORD: A Peer-to-Peer Lookup ServiceCHORD: A Peer-to-Peer Lookup Service
Ion Stoica Robert Morris David R. Karger
M. Frans Kaashoek Hari Balakrishnan
Presented By
Mohammad Malli
PhD student (2nd year)
Planete Project
March 14, 2005 2
Internet
N1
N2 N3
N6N5
N4
PublisherClient
Lookup(“title”)
?Key=“title”Value=MP3 data…
The Lookup Problem
March 14, 2005 3
Publisher@
Client
Lookup(“title”)
N6
N9 N7
DB
N8
N3
N2N1SetLoc(“title”, N4)
Simple, but O(N) state and a single point of failure
Key=“title”Value=MP3 data…
N4
Centralized Lookup (Napster)
March 14, 2005 4
Flooded queries (Gnutella)
N4Publisher@
Client
N6
N9
N7N8
N3
N2N1
Robust, but worst case O(N) messages per lookup
Key=“title”Value=MP3 data…
Lookup(“title”)
March 14, 2005 5
Routed queries (Freenet, Chord, etc.)
N4Publisher
Client
N6
N9
N7N8
N3
N2N1
Lookup(“title”)
Key=“title”Value=MP3 data…
March 14, 2005 6
What is Chord ?
A peer-to-peer lookup system Given a key (data item), it maps the key onto a node
(peer). Uses consistent hashing to assign keys to nodes . Solves problem of locating key in a collection of
distributed nodes. Maintains routing information as nodes join and leave the
system
March 14, 2005 7
Routing Challenges
Define a useful key nearness metric
Keep the hop count small
Keep the tables small
Stay robust despite rapid change
Chord: emphasizes efficiency and simplicity
March 14, 2005 8
Load Balance: Distributed hash function spreads keys equally over the nodes
Decentralization: Fully distributed
Scalability: Lookup grows as a log of number of nodes
Availability: Automatically adjusts internal tables to reflect changes.
Flexible Naming: No constraints on key structure.
Chord : main features
March 14, 2005 9
Chord Protocol
Hash function balances the load
Assigns each node and key an m-bit identifier using SHA-1 base hash function
Node’s IP address is hashed
Identifiers are ordered on a identifier circle modulo 2m called a chord ring
succesor(k) = first node whose identifier is >= identifier of k in identifier space
March 14, 2005 10
For m = 6, # of identifiers is 64 The following Chord ring has 10 nodes and stores 5 keys The successor of key 10 is node 14, ...
Chord Protocol
March 14, 2005 11
If each node knows only how to contact its current successor node on the identifier circle, all node can be visited in linear order. Queries for a given identifier could be passed around the circle via these successor pointers until they encounter the node that contains the key
Simple Key Lookup
March 14, 2005 12
To accelerate lookups, Chord maintains additional routing information The ith entry in the table at node n contains the identity of the first node s that succeeds n by at least 2i-1 on the identifier circle. s = successor(n+2i-1)
is called the ith finger of node n, denoted by n.finger(i)
A finger table entry includes both the Chord identifier and the IP address (and port number) of the relevant node. The first finger of n is the immediate successor of n on the circle Each node forwards query at least halfway along distance remaining to the target Theorem: With high probability, the number of nodes that must be contacted to find a successor in a N-node network is O(log N)
Scalable Key Lookup
March 14, 2005 13
The path a query for key 54 starting at node 8 :
Scalable Key Lookup
March 14, 2005 14
When a node n joins the network, certain keys previously assigned to n’s successor now become assigned to n
When node n leaves the network, all of its assigned keys are reassigned to n’s successor.
Join & Departure
March 14, 2005 15
The most important thing is the successor pointer
If the successor pointer is ensured to be up to date, which is sufficient to guarantee correctness of lookups, then finger table can always be verified
Each node runs a “stabilization” protocol periodically in the background to update successor pointer and finger table
Stabilization
March 14, 2005 16
Failures solution: successor lists
Each node knows r immediate successors
After failure, it will identify first live successor
Correct successors guarantee correct lookups
Guarantee is with some probability
March 14, 2005 18
Backup
March 14, 2005 19
Node Joins and Stabilizations
“Stabilization” protocol contains 6 functions:create()join()stabilize()notify()fix_fingers()check_predecessor()
March 14, 2005 20
• Creates a new Chord ring
n.create()predecessor = nil;successor = n;
Create()
March 14, 2005 21
join()
• Asks m to find the immediate successor of n.• Doesn’t make rest of the network aware of n.
n.join(m)predecessor = nil;successor = m.find_successor(n);
March 14, 2005 22
Stabilize()
• Called periodically to learn about new nodes• Asks n’s immediate successor about successor’s predecessor p
– Checks whether p should be n’s successor instead– Also notifies n’s successor about n’s existence, so that successor may
change its predecessor to n, if necessary
n.stabilize()x = successor.predecessor;if (x (n, successor))
successor = x;successor.notify(n);
March 14, 2005 23
Notify()
• m thinks it might be n’s predecessor
n.notify(m)if (predecessor is nil or m (predecessor, n))
predecessor = m;
March 14, 2005 24
Fix_fingers()
• Periodically called to make sure that finger table entries are correct– New nodes initialize their finger tables– Existing nodes incorporate new nodes into their finger tables
n.fix_fingers()next = next + 1 ;if (next > m)
next = 1 ;finger[next] = find_successor(n + 2next-1);
March 14, 2005 25
Check_predecessor()
• Periodically called to check whether predecessor has failed– If yes, it clears the predecessor pointer, which can then
be modified by notify()
n.check_predecessor()if (predecessor has failed)
predecessor = nil;