Chord- A Scalable Peer-to-Peer Lookup Service for Internet Applications
CHORD: A SCALABLE PEER-TO-PEERLOOKUP SERVICE FOR INTERNETAPPLICATIONS Ion Stoica Robert Morris David Liben-Nowell David R. Karger M. Frans Kaashoek Frank Dabek Hari Balakrishnan Presented By- Chaitanya Pratap MCA(4th Semester) South Asian University, New Delhi.
INTRODUCTION A fundamental problem that confronts peer-to-peer applications is to efficiently locate the node that stores a particular data item. Chord provides support for just one operation: given a key, it maps the key onto a node. Data location can be easily implemented on top of Chord by associating a key with each data item, and storing the key/data item pair at the node to which the key maps.
SYSTEM MODEL (FEATURES) Load balance: Chord acts as a distributed hash function, spreading keys evenly over the nodes. this provides a degree of natural load balance. Decentralization: Chord is fully distributed: no node is more important than any other. This improves robustness.
CONT… Scalability: The cost of a Chord lookup grows as the log of the number of nodes, so even very large systems are feasible. Availability: Chord automatically adjusts its internal tables to reflect newly joined nodes as well as node failures, ensuring that the node responsible for a key can always be found. Flexible naming: Chord places no constraints on the structure of the keys it looks up: the Chord key- space is flat.
THE BASE CHORD PROTOCOL The Chord protocol specifies how to find the locations of keys, how new nodes join the system, and how to recover from the failure (or planned departure) of existing nodes.
OVERVIEW Chord provides fast distributed computation of a hash function mapping keys to nodes responsible for them. when an Nth node joins (or leaves) the network, only an O(1/N) fraction of the keys are moved to a different location A Chord node needs only a small amount of “routing” information about other nodes. In an N node network, each node maintains information only about O(log N) other nodes, and a lookup requires O(log N) messages. a join or leave requires O(log N^2) messages.
CONSISTENT HASHING Consistent hashing is designed to let nodes enter and leave the network with minimal disruption. To maintain the consistent hashing mapping 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.
SCALABLE KEY LOCATION This scheme has two important characteristics. First, each node stores information about only a small number of other nodes, it only knows about closer nodes. Second, a node’s finger table generally does not contain enough information to determine the successor of an arbitrary key.
NODE JOINS Initialize the predecessor and fingers of node n. Update the fingers and predecessors of existing nodes to reflect the addition of n. Notify the higher layer software so that it can transfer state (e.g. values) associated with keys that node n is now responsible for.
IMPACT OF NODE JOINS ONLOOKUPS Correctness If finger table entries are reasonably current Lookup finds the correct successor in O(log N) steps If successor pointers are correct but finger tables are incorrect Correct lookup but slower If incorrect successor pointers Lookup may fail
IMPACT OF NODE JOINS ON LOOKUPS Performance If stabilization is complete Lookup can be done in O(log N) time If stabilization is not complete Existing nodes finger tables may not reflect the new nodes Doesn’t significantly affect lookup speed Newly joined nodes can affect the lookup speed, if the new nodes ID’s are in between target and target’s predecessor Lookup will have to be forwarded through the intervening nodes, one at a time
STABILIZATION AFTER JOIN n joins ns predecessor = nil n acquires ns as successor via some n’ n notifies ns being the new predecessor pred(ns) = n ns acquires n as its predecessor np runs stabilize np asks ns for its predecessor (now n) n succ(np) = ns np acquires n as its successor pred(ns) = np np notifies n n will acquire np as its predecessor succ(np) = n nil all predecessor and successor pointers are now correct fingers still need to be fixed, but old fingers will still work np 13
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 14
FAILURE RECOVERY Key step in failure recovery is maintaining correct successor pointers To help achieve this, each node maintains a successor-list of its r nearest successors on the ring If node n notices that its successor has failed, it replaces it with the first live entry in the list stabilize will correct finger table entries and successor-list entries pointing to failed node Performance is sensitive to the frequency of node joins and leaves versus the frequency at which the stabilization protocol is invoked 15
SIMULATION Protocol Simulator: The Chord protocol can be implemented in an iterative or recursive style. In the iterative style, a node resolving a lookup initiates all communication: it asks a series of nodes for information from their finger tables, each time moving closer on the Chord ring to the desired successor. In the recursive style, each intermediate node forwards a request to the next node until it reaches the successor. The simulator implements the protocols in an iterative style.
EXPERIMENTAL RESULTS Latency grows slowly with the total number of nodes Path length for lookups is about ½ log2N Chord is robust in the face of multiple node failures 17
CONCLUSION Efficient location of the node that stores a desired data item is a fundamental problem in P2P networks Chord protocol solves it in a efficient decentralized manner Routing information: O(log N) nodes Lookup: O(log N) nodes Update: O(log2 N) messages Italso adapts dynamically to the topology changes introduced during the run
FUTURE WORK Using Chord to detect and heal partitions whose nodes know of each other. Every node should know of some same set of initial nodes Nodes should maintain long-term memory of a random set of nodes that they have visited earlier Malicious set of Chord participants could present an incorrect view of the Chord ring Node n periodically asks other nodes to do a lookup for n
REFERENCES Chord: A Scalable Peer-to-Peer Lookup Service for Internet Applications by Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, Hari Balakrishnan.