Peer-To-Peer Chord

In computing, Chord is a protocol and algorithm for a peer-to-peer distributed hash table.

A distributed hash table stores key-value pairs by assigning keys to different computers (known as "nodes"); a node will store the values for all the keys for which it is responsible. Chord specifies how keys are assigned to nodes, and how a node can discover the value for a given key by first locating the node responsible for that key.

Chord is one of the four original distributed hash table protocols, along with CAN, Tapestry, and Pastry. It was introduced in 2001 by Ion Stoica, Robert Morris, David Karger, Frans Kaashoek, and Hari Balakrishnan, and was developed at MIT. The 2001 Chord paper won an ACM SIGCOMM Test of Time award in 2011.

Subsequent research by Pamela Zave has shown that the original Chord algorithm (as specified in the 2001 SIGCOMM paper, the 2001 Technical report, the 2002 PODC paper, and the 2003 TON paper ) can mis-order the ring, produce several rings, and break the ring.

Overview

Peer-To-Peer Chord 

Nodes and keys are assigned an Peer-To-Peer Chord -bit identifier using consistent hashing. The SHA-1 algorithm is the base hashing function for consistent hashing. Consistent hashing is integral to the robustness and performance of Chord because both keys and nodes (in fact, their IP addresses) are uniformly distributed in the same identifier space with a negligible possibility of collision. Thus, it also allows nodes to join and leave the network without disruption. In the protocol, the term node is used to refer to both a node itself and its identifier (ID) without ambiguity. So is the term key.

Using the Chord lookup protocol, nodes and keys are arranged in an identifier circle that has at most Peer-To-Peer Chord  nodes, ranging from Peer-To-Peer Chord  to Peer-To-Peer Chord . (Peer-To-Peer Chord  should be large enough to avoid collision.) Some of these nodes will map to machines or keys while others (most) will be empty.

Each node has a successor and a predecessor. The successor to a node is the next node in the identifier circle in a clockwise direction. The predecessor is counter-clockwise. If there is a node for each possible ID, the successor of node 0 is node 1, and the predecessor of node 0 is node Peer-To-Peer Chord ; however, normally there are "holes" in the sequence. For example, the successor of node 153 may be node 167 (and nodes from 154 to 166 do not exist); in this case, the predecessor of node 167 will be node 153.

The concept of successor can be used for keys as well. The successor node of a key Peer-To-Peer Chord  is the first node whose ID equals to Peer-To-Peer Chord  or follows Peer-To-Peer Chord  in the identifier circle, denoted by Peer-To-Peer Chord . Every key is assigned to (stored at) its successor node, so looking up a key Peer-To-Peer Chord  is to query Peer-To-Peer Chord .

Since the successor (or predecessor) of a node may disappear from the network (because of failure or departure), each node records an arc of Peer-To-Peer Chord  nodes in the middle of which it stands, i.e., the list of Peer-To-Peer Chord  nodes preceding it and Peer-To-Peer Chord  nodes following it. This list results in a high probability that a node is able to correctly locate its successor or predecessor, even if the network in question suffers from a high failure rate.

Protocol details

Peer-To-Peer Chord 
A 16-node Chord network. The "fingers" for one of the nodes are highlighted.

Basic query

The core usage of the Chord protocol is to query a key from a client (generally a node as well), i.e. to find Peer-To-Peer Chord . The basic approach is to pass the query to a node's successor, if it cannot find the key locally. This will lead to a Peer-To-Peer Chord  query time where Peer-To-Peer Chord  is the number of machines in the ring.

Finger table

To avoid the linear search above, Chord implements a faster search method by requiring each node to keep a finger table containing up to Peer-To-Peer Chord  entries, recall that Peer-To-Peer Chord  is the number of bits in the hash key. The Peer-To-Peer Chord  entry of node Peer-To-Peer Chord  will contain Peer-To-Peer Chord . The first entry of finger table is actually the node's immediate successor (and therefore an extra successor field is not needed). Every time a node wants to look up a key Peer-To-Peer Chord , it will pass the query to the closest successor or predecessor (depending on the finger table) of Peer-To-Peer Chord  in its finger table (the "largest" one on the circle whose ID is smaller than Peer-To-Peer Chord ), until a node finds out the key is stored in its immediate successor.

With such a finger table, the number of nodes that must be contacted to find a successor in an N-node network is Peer-To-Peer Chord . (See proof below.)

Node join

Whenever a new node joins, three invariants should be maintained (the first two ensure correctness and the last one keeps querying fast):

  1. Each node's successor points to its immediate successor correctly.
  2. Each key is stored in Peer-To-Peer Chord .
  3. Each node's finger table should be correct.

To satisfy these invariants, a predecessor field is maintained for each node. As the successor is the first entry of the finger table, we do not need to maintain this field separately any more. The following tasks should be done for a newly joined node Peer-To-Peer Chord :

  1. Initialize node Peer-To-Peer Chord  (the predecessor and the finger table).
  2. Notify other nodes to update their predecessors and finger tables.
  3. The new node takes over its responsible keys from its successor.

The predecessor of Peer-To-Peer Chord  can be easily obtained from the predecessor of Peer-To-Peer Chord  (in the previous circle). As for its finger table, there are various initialization methods. The simplest one is to execute find successor queries for all Peer-To-Peer Chord  entries, resulting in Peer-To-Peer Chord  initialization time. A better method is to check whether Peer-To-Peer Chord  entry in the finger table is still correct for the Peer-To-Peer Chord  entry. This will lead to Peer-To-Peer Chord . The best method is to initialize the finger table from its immediate neighbours and make some updates, which is Peer-To-Peer Chord .

Stabilization

To ensure correct lookups, all successor pointers must be up to date. Therefore, a stabilization protocol is running periodically in the background which updates finger tables and successor pointers.

The stabilization protocol works as follows:

  • Stabilize(): n asks its successor for its predecessor p and decides whether p should be n's successor instead (this is the case if p recently joined the system).
  • Notify(): notifies n's successor of its existence, so it can change its predecessor to n
  • Fix_fingers(): updates finger tables

Potential uses

  • Cooperative Mirroring: A load balancing mechanism by a local network hosting information available to computers outside of the local network. This scheme could allow developers to balance the load between many computers instead of a central server to ensure availability of their product.
  • Time-shared storage: In a network, once a computer joins the network its available data is distributed throughout the network for retrieval when that computer disconnects from the network. As well as other computers' data is sent to the computer in question for offline retrieval when they are no longer connected to the network. Mainly for nodes without the ability to connect full-time to the network.
  • Distributed Indices: Retrieval of files over the network within a searchable database. e.g. P2P file transfer clients.
  • Large scale combinatorial searches: Keys being candidate solutions to a problem and each key mapping to the node, or computer, that is responsible for evaluating them as a solution or not. e.g. Code Breaking
  • Also used in wireless sensor networks for reliability

Proof sketches

Peer-To-Peer Chord 
The routing path between nodes A and B. Each hop cuts the remaining distance in half (or better).

With high probability, Chord contacts Peer-To-Peer Chord  nodes to find a successor in an Peer-To-Peer Chord -node network.

Suppose node Peer-To-Peer Chord  wishes to find the successor of key Peer-To-Peer Chord . Let Peer-To-Peer Chord  be the predecessor of Peer-To-Peer Chord . We wish to find an upper bound for the number of steps it takes for a message to be routed from Peer-To-Peer Chord  to Peer-To-Peer Chord . Node Peer-To-Peer Chord  will examine its finger table and route the request to the closest predecessor of Peer-To-Peer Chord  that it has. Call this node Peer-To-Peer Chord . If Peer-To-Peer Chord  is the Peer-To-Peer Chord  entry in Peer-To-Peer Chord 's finger table, then both Peer-To-Peer Chord  and Peer-To-Peer Chord  are at distances between Peer-To-Peer Chord  and Peer-To-Peer Chord  from Peer-To-Peer Chord  along the identifier circle. Hence, the distance between Peer-To-Peer Chord  and Peer-To-Peer Chord  along this circle is at most Peer-To-Peer Chord . Thus the distance from Peer-To-Peer Chord  to Peer-To-Peer Chord  is less than the distance from Peer-To-Peer Chord  to Peer-To-Peer Chord : the new distance to Peer-To-Peer Chord  is at most half the initial distance.

This process of halving the remaining distance repeats itself, so after Peer-To-Peer Chord  steps, the distance remaining to Peer-To-Peer Chord  is at most Peer-To-Peer Chord ; in particular, after Peer-To-Peer Chord  steps, the remaining distance is at most Peer-To-Peer Chord . Because nodes are distributed uniformly at random along the identifier circle, the expected number of nodes falling within an interval of this length is 1, and with high probability, there are fewer than Peer-To-Peer Chord  such nodes. Because the message always advances by at least one node, it takes at most Peer-To-Peer Chord  steps for a message to traverse this remaining distance. The total expected routing time is thus Peer-To-Peer Chord .

If Chord keeps track of Peer-To-Peer Chord  predecessors/successors, then with high probability, if each node has probability of 1/4 of failing, find_successor (see below) and find_predecessor (see below) will return the correct nodes

Simply, the probability that all Peer-To-Peer Chord  nodes fail is Peer-To-Peer Chord , which is a low probability; so with high probability at least one of them is alive and the node will have the correct pointer.

Pseudocode

    Definitions for pseudocode
      finger[k]
      first node that succeeds Peer-To-Peer Chord 
      successor
      the next node from the node in question on the identifier ring
      predecessor
      the previous node from the node in question on the identifier ring

The pseudocode to find the successor node of an id is given below:

// ask node n to find the successor of id n.find_successor(id)     // Yes, that should be a closing square bracket to match the opening parenthesis.     // It is a half closed interval.     if id ∈ (n, successor] then         return successor     else         // forward the query around the circle         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 do         if (finger[i] ∈ (n, id)) then             return finger[i]     return n 

The pseudocode to stabilize the chord ring/circle after node joins and departures is as follows:

// create a new Chord ring. n.create()     predecessor := nil     successor := n  // join a Chord ring containing node n'. n.join(n')     predecessor := nil     successor := n'.find_successor(n)  // called periodically. n asks the successor // about its predecessor, verifies if n's immediate // successor is consistent, and tells the successor about n n.stabilize()     x = successor.predecessor     if x ∈ (n, successor) then         successor := x     successor.notify(n)  // n' thinks it might be our predecessor. n.notify(n')     if predecessor is nil or n'∈(predecessor, n) then         predecessor := n'  // called periodically. refreshes finger table entries. // next stores the index of the finger to fix n.fix_fingers()     next := next + 1     if next > m then         next := 1     finger[next] := find_successor(n+2next-1);  // called periodically. checks whether predecessor has failed. n.check_predecessor()     if predecessor has failed then         predecessor := nil 

See also

References

Tags:

Peer-To-Peer Chord OverviewPeer-To-Peer Chord Protocol detailsPeer-To-Peer Chord Potential usesPeer-To-Peer Chord Proof sketchesPeer-To-Peer Chord PseudocodePeer-To-Peer ChordAlgorithmAssociative arrayComputingDistributed hash tablePeer-to-peer

🔥 Trending searches on Wiki English:

Indian Premier LeagueGeorge WashingtonEaster eggRachel McAdamsEngland national football teamSandy Hook Elementary School shootingRebekah NeumannUEFA European ChampionshipXVideosCleopatraDrake (musician)Islamic State – Khorasan ProvinceNepalNicole ShanahanApril Fools' DayDakota JohnsonNicholas GalitzineList of countries by GDP (nominal)Matthew McConaugheyTeri Baaton Mein Aisa Uljha JiyaAditi Rao HydariNorovirusList of country calling codesShohei OhtaniJeffrey DahmerMargaret QualleyElectoral BondBaltimore2024 ICC Men's T20 World CupDonald TrumpAbby and Brittany HenselFIFA World CupGrey's AnatomyBassirou Diomaye FayeThe Amanda ShowAndre Jin CoquillardGenghis KhanEdward VIIIPope FrancisKwena MaphakaStevie JAlbert EinsteinYorgos LanthimosElizabeth TaylorFermi paradoxMasters of the AirSagittarius A*ChinaLisa LillienMount TakaheLiam CunninghamSergey BrinJoe RoganMurder of Ella BennettUkraineLarry DavidLucian GraingeThe Black PhoneJujutsu KaisenAbbas AnsariLondonGame Changer (film)Cassie VenturaPat KelseyStranger ThingsEgyptJ. Robert OppenheimerAll ThatFrierenJalen GreenJeffrey EpsteinWordleSamantha MortonCaroline EllisonDanielle CollinsResident Alien (TV series)Vietnam War🡆 More