1. 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

2. Table of Contents What is P2P system? Lookup problem What is Chord? Chord algorithm Acceleration of lookup Operations on Chord Open Issues

3. 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

4. Lookup problem Internet N1N1 N2N2 N3N3 N4N4 N5N5 N6N6 Publisher File “XYZ” Client Lookup(“XYZ”)‏ ? N7N7 Internet

5. Centralized lookup (Napster)‏ Publisher Client Lookup(“XYZ”)‏ N6N6 N5N5 DB N4N4 N3N3 N2N2 N1N1 Simple, but a single point of failure N7N7 File “XYZ”

6. Flooded queries (Gnutella)‏ N4N4 Publisher Client N6N6 N9N9 N7N7 N8N8 N3N3 N2N2 N1N1 Robust, but wastage of network bandwidth File “XYZ” Lookup(“XYZ”)‏

7. 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. 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. 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. 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

11. 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?

12. 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

13. 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. 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

15. Scalable Lookup Scheme N1 N8 N14 N21 N32 N38 N42 N48 N51 N56 N42N8+32 N32N8+16 N21N8+8 N14N8+4 N14N8+2 N14N8+1 Finger Table for N8 finger 1,2,3 finger 4 finger 6 finger [k] = first node that succeeds (n+2 k-1 )mod2 m finger 5

16. 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;

17. Lookup Using Finger Table take O( log(N) ) hops N1 N8 N14 N21 N32 N38 N42 N51 N56 N48 lookup(54)‏

18. Joining N5 N10 N1 1. Lookup(5)‏ K3 K6

19. Join (2)‏ N5 N10 N1 2. N5 sets its own successor pointer K3 K6

20. Join (3)‏ N5 N10 N1 3. Copy keys 2..5 from N10 to N5 K3 K6 K3

21. 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. 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. 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

24. 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.

25. 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;

26. Concurrent Join New node n n1 n2 [Before] New node n n2 n1 [After] New node n’

27. 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.

28. Failures might cause incorrect lookup N42 N38 N21 N8 N14 N8 doesn’t know correct successor, so incorrect lookup N1 Lookup(30)‏

29. 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

30. 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

31. 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.

32. Open Issues Network proximity Malicious data insertion Malicious Chord table information Anonymity

33. 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.

34. ?

35. Thank you !