Understanding Distributed Hash Tables: A Look at CAN and Coral, Study notes of Software Engineering

Download Understanding Distributed Hash Tables: A Look at CAN and Coral and more Study notes Software Engineering in PDF only on Docsity!

Distributed Software

Development

More Distributed Hash Tables

Chris Brooks Department of Computer ScienceUniversity of San Francisco^ Department of Computer Science — University of San Francisco – p. 1/

Distributed Hash Tables

-^ On Tuesday, we talked about Distributed Hash Tables^ •^

Used Chord as an example

-^ Able to act as a distributed storage and indexing mechanism •^ Maps “keys” (hashes of data) to “values” (coordinates in aspace of nodes.) •^ Each node is responsible for a set of the keyspace.

Department of Computer Science — University of San Francisco – p. 2/

Chord

-^ Recall that Chord uses a 1-D ring to structure the network. •^ Nodes keep a

finger table

that tells them the successors at

various points in the network. • Routing requires

O(logn

)^ messages.

-^ Can tolerate failures through replication of data.

Department of Computer Science — University of San Francisco – p. 4/

CAN

-^ CAN stands for Content Addressable Network •^ Developed at Berkeley at the same time as Chord wasdeveloped at MIT. •^ Also provides hash-table like functionality.^ •^

get, store, delete

Department of Computer Science — University of San Francisco – p. 5/

Example

-^ An example CAN in a 2-Dspace. •^ Node 1 is responsible fordata in the range( (0-0.25), (0.5-1) ) •^ Node 4 is responsible fordata in the range( (0.5-1), (0.5-1) ) Department of Computer Science — University of San Francisco – p. 7/

Routing in CAN

-^ Each node keeps track of the IP address and zone of itsneighbors. •^ A neighbor is a node whose zone overlaps a node in

n^ −^1

dimensions, and abuts it in the

nth dimension.

-^ In our example, 2,3, and 4 are neighbors of 1.^ •^

Remember that the space is really a torus.

-^ Routing is done by greedy search. •^ Always forward the message to the neighbor who is closestto the data, using standard Euclidean distance. (ties brokenrandomly)

Department of Computer Science — University of San Francisco – p. 8/

Node joining

-^ New nodes are added to the system by choosing an existingzone and subdividing it. •^ First, the new node must find an existing bootstrap node. •^ Then it must find its coordinates within CAN •^ Finally, it must update its neighbors’ routing tables.

Department of Computer Science — University of San Francisco – p. 10/

Node joining - bootstrapping • It is assumed that the IP address of at least one currentCAN node is known to the joining node. • The designers use DNS to map a CAN hostname to one ormore CAN nodes. • This bootstrap node can provide the IP addresses of othernodes in the network that can be used as entry points.

Department of Computer Science — University of San Francisco – p. 11/

Node joining - updating neighbors •^ Once the zone has been partitioned, all neighbors need toupdate their routing tables. •^ New node gets the routing table from the node whose zoneit split. •^ Adds node whose zone it split, and removes allnon-neighbors. •^ Split node removes non-neighbors as well. •^ Both nodes send update messages to all affected nodes.

Department of Computer Science — University of San Francisco – p. 13/

Example

-^ Initially, 3’s neighbors are 1,2and 5. •^ 6 joins and splits 3’s zone alongthe x axis. •^ 6 gets 3’s list of neighghbors •^ 6 adds 3 to its neighbor list andsends an update to 1,2, and 5 •^ 3 adds 6 to its list of neighbors •^ 3 removes 1 and 2 from its listof neighbors and sends them anupdate. Department of Computer Science — University of San Francisco – p. 14/

Handling Failure

-^ CAN nodes send periodic “I’m alive” messages to theirneighbors^ •^

Contains a node’s zone coordinates and their neighborsand their coordinates.

-^ If a node does not receive an “I’m alive” message after agiven time period, it begins a takeover.

Department of Computer Science — University of San Francisco – p. 16/

Handling Failure

-^ To begin, it starts a timer^ •^

Length is proportionate to its zone size. • Intuition: we want to merge smaller zones

-^ Once the timer expires, send a TAKEOVER message to allof the failed node’s neighbors. •^ When a TAKEOVER message is received, a node turns offits own timer if the zone volume of the sender is less thanits own. •^ Otherwise, it replies with its own TAKEOVER message.^ •^

Somewhat like leader election.

Department of Computer Science — University of San Francisco – p. 17/

provements: multiple coordinate spac^ •^ One improvement is to maintain multiple coordinate spaces.^ •^ Each node is assigned a different zone in each coordinatespace, or “reality”.^ •^ Contents are replicated for each reality.^ •^ If there are

r^ realities, this means that

r^ copies of the data

are stored in the network. • This provides fault tolerance. • By translating routing messages between realities, nodes canpotentially find shorter-latency routes between nodes.

Department of Computer Science — University of San Francisco – p. 19/

Improved routing metrics

-^ The basic CAN routing algorithm uses greedy search. Itchooses the node that produces the greatest reduction indistance between the present node and the data to be found. •^ An alternative is to also measure the round-trip-timebetween a node and each of its neighbors. •^ When choosing where to forward a packet, select the nodethat maximizes progress over RTT. •^ This favors low-latency paths at the IP level.

Department of Computer Science — University of San Francisco – p. 20/