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

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

March 14, 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)

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

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

March 14, 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, 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, ò 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, 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

March 14, ò 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, ò 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, ò 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

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

March 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, ò 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, 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, Thank you Q & A

March 14, Backup

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

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

March 14, 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, 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, Notify() m thinks it might be n’s predecessor n.notify(m) if (predecessor is nil or m  (predecessor, n)) predecessor = m;

March 14, 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 );

March 14, 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;