1. CHORD: A Peer-to-Peer Lookup Service CHORD: A Peer-to-Peer Lookup Service Ion StoicaRobert Morris David R. Karger M. Frans Kaashoek Hari Balakrishnan Presented By Mohammad Malli PhD student (2nd year) Planete Project

2. March 14, 2005 2 Internet N1N1 N2N2 N3N3 N6N6 N5N5 N4N4 Publisher Client Lookup(“title”) ? Key=“title” Value=MP3 data… The Lookup Problem

3. March 14, 2005 3 Publisher@ Client Lookup(“title”) N6N6 N9N9 N7N7 DB N8N8 N3N3 N2N2 N1N1 SetLoc(“title”, N4) Simple, but O(N) state and a single point of failure Key=“title” Value=MP3 data… N4N4 Centralized Lookup (Napster)

4. March 14, 2005 4 Flooded queries (Gnutella) N4N4 Publisher@ Client N6N6 N9N9 N7N7 N8N8 N3N3 N2N2 N1N1 Robust, but worst case O(N) messages per lookup Key=“title” Value=MP3 data… Lookup(“title”)

5. March 14, 2005 5 Routed queries (Freenet, Chord, etc.) N4N4 Publisher Client N6N6 N9N9 N7N7 N8N8 N3N3 N2N2 N1N1 Lookup(“title”) Key=“title” Value=MP3 data…

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

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

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

9. 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 2 m called a chord ring ò succesor(k) = first node whose identifier is >= identifier of k in identifier space

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

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

12. March 14, 2005 12 ò To accelerate lookups, Chord maintains additional routing information ò The 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 ) is called the i th 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

13. March 14, 2005 13 The path a query for key 54 starting at node 8 : Scalable Key Lookup

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

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

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

17. March 14, 2005 17 Thank you Q & A Mohammad.Malli@sophia.inria.fr

18. March 14, 2005 18 Backup

19. March 14, 2005 19 Node Joins and Stabilizations “Stabilization” protocol contains 6 functions: create() join() stabilize() notify() fix_fingers() check_predecessor()

20. March 14, 2005 20 Creates a new Chord ring n.create() predecessor = nil; successor = n; Create()

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

22. 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);

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

24. 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 + 2 next-1 );

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