Presentation on theme: "Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications Ion StoicaRobert Morris David Liben-NowellDavid R. Karger M. Frans KaashoekFrank."— Presentation transcript:
Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications Ion StoicaRobert Morris David Liben-NowellDavid R. Karger M. Frans KaashoekFrank Dabek Hari Balakrishnan Presented By- Bhushan Sonawane University of Maryland Baltimore County
Table of Contents What is P2P system? Lookup problem What is Chord? Chord algorithm Acceleration of lookup Operations on Chord Open Issues
What is a P2P system? A distributed system architecture: No centralized control Nodes are symmetric in function Larger number of unreliable nodes Enabled by technology improvements Node Internet
Lookup problem Internet N1N1 N2N2 N3N3 N4N4 N5N5 N6N6 Publisher File “XYZ” Client Lookup(“XYZ”) ? N7N7 Internet
Centralized lookup (Napster) Publisher Client Lookup(“XYZ”) N6N6 N5N5 DB N4N4 N3N3 N2N2 N1N1 Simple, but a single point of failure N7N7 File “XYZ”
7 What is Chord? A peer-to-peer lookup service Provides peer-to-peer hash lookup: Lookup(key) IP address Chord does not store the data Solves problem of locating a data item in a collection of distributed nodes, considering frequent node arrivals and departures
8 Addressed Difficult Problems (1) Load balance: distributed hash function, spreading keys evenly over nodes Decentralization: chord is fully distributed, no node more important than other, improves robustness Scalability: logarithmic growth of lookup costs with number of nodes in network, even very large systems are feasible
9 Addressed Difficult Problems (2) Availability: chord automatically adjusts its internal tables to ensure that the node responsible for a key can always be found Flexible naming: no constraints on the structure of the keys – key-space is flat, flexibility in how to map names to Chord keys
10 Chord Characteristics Interface: lookup(key) IP address Efficient: O( log(N) ) messages per lookup N is the total number of servers Scalable: O( log(N) ) state per node Robust: survives massive failures Simple to analyze
Chord IDs Key identifier = SHA-1(key) Node identifier = SHA-1(IP address) SHA-1 distributes both uniformly How to map key IDs to node IDs?
Chord Hashes a Key to its Successor N32 N10 N100 N80 N60 Circular ID Space Successor: node with next highest ID K33, K40, K52 K11, K30 K5, K10 K65, K70 K99 Key ID Node ID
Basic Lookup N32 N10 N5 N20 N110 N99 N80 N60 N40 “Where is key 50?” “Key 50 is At N60” Lookups find the ID’s predecessor Correct if successors are correct
14 Acceleration of Lookups Lookups are accelerated by maintaining additional routing information Each node maintains a routing table with (at most) m entries (where N=2 m ) called the finger table i th entry in the table at node n contains the identity of the first node, s, that succeeds n by at least 2 i-1 on the identifier circle s = successor(n + 2 i-1 ) (all arithmetic mod 2 m ) s is called the i th finger of node n, denoted by n.finger(i).node
Scalable Lookup Scheme // ask node n to find the successor of id n.find_successor(id) if (id belongs to (n, successor]) return successor; else n0 = closest preceding node(id); return n0.find_successor(id); // search the local table for the highest predecessor of id n.closest_preceding_node(id) for i = m downto 1 if (finger[i] belongs to (n, id)) return finger[i]; return n;
Join (2) N5 N10 N1 2. N5 sets its own successor pointer K3 K6
Join (3) N5 N10 N1 3. Copy keys 2..5 from N10 to N5 K3 K6 K3
Join (4) N5 N10 N1 4. Set N5’s successor pointer Update finger pointers in the background Correct successors produce correct lookups K6 K3
22 Source of Inconsistencies: Concurrent Operations and Failures Basic “stabilization” protocol is used to keep nodes’ successor pointers up to date, which is sufficient to guarantee correctness of lookups Those successor pointers can then be used to verify the finger table entries Every node runs stabilize periodically to find newly joined nodes
23 Stabilization after Join n joins predecessor = nil n acquires n s as successor via some n’ n notifies n s being the new predecessor n s acquires n as its predecessor n p runs stabilize n p asks n s for its predecessor (now n) n p acquires n as its successor n p notifies n n will acquire n p as its predecessor
Node Joins – fix_fingers() Each node periodically calls fix fingers to make sure its finger table entries are correct. It is how new nodes initialize their finger tables It is how existing nodes incorporate new nodes into their finger tables.
Node Joins – fix_fingers() // called periodically. refreshes finger table entries. n.fix_fingers() next = next + 1 ; if (next > m) next = 1 ; finger[next] = find_successor(n + 2 next-1 );find_successor // checks whether predecessor has failed. n.check_predecessor() if (predecessor has failed) predecessor = nil;
Concurrent Join New node n n1 n2 [Before] New node n n2 n1 [After] New node n’
The complexity of join With high probability, any node joining or leaving an N-node Chord network will use O(log 2 N) messages to re-establish the Chord routing invariants and finger tables.
Solution: successor lists Each node knows r immediate successors After failure, will know first live successor Correct successors guarantee correct lookups Guarantee is with some probability
Lookup with fault tolerance Lookup(my-id, key-id) look in local finger table and successor-list for highest node n s.t. my-id < n < key-id if n exists call Lookup(id) on node n // next hop if call failed, remove n from finger table return Lookup(my-id, key-id) else return my successor // done
Chord Summary Log(n) lookup messages and table space. Well-defined location for each ID. No search required. Natural load balance. No name structure imposed. Minimal join/leave disruption.
Open Issues Network proximity Malicious data insertion Malicious Chord table information Anonymity
References Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, and Hari Balakrishnan, Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications, ACM SIGCOMM 2001, San Deigo, CA, August 2001. Ion Stoica, Robert Morris, David Liben-Nowell, David R. Karger, M. Frans Kaashoek, Frank Dabek, Hari Balkrishnan. Chord: A scalable peer-to- peer lookup protocol for Internet applications. IEEE/ACM Transactions on Networking, Vol. 11, No. 1, PP. 17-32, Feb 2003.