The Content Addressable Network (CAN) is a decentralized, distributed P2P infrastructure that delivers

Internet-scale hash table capabilities. CAN was one of the initial four distributed hash table proposals, along
with Chord, Pastry, and Tapestry, which were all introduced at the same time.

Overview

CAN is supposed to be scalable, fault-tolerant, and self-organizing, just like other distributed hash tables. The
architectural design is a multi-torus overlay network with a virtual multi-dimensional Cartesian coordinate
system. This n-dimensional coordinate space is a virtual logical address that is unaffected by the nodes'
physical location or connectivity. Coordinates are used to identify points in space. Every node in the system
has at least one separate zone inside the overall coordinate space, which is dynamically partitioned across all
nodes in the system.

Routing

A CAN node keeps a routing table with each of its neighbors’ IP address and virtual coordinate zone. A node
directs a message to a coordinate space destination point. The node decides which neighboring zone is
closest to the target point, then uses the routing table to find up the IP address of that zone's node.

Node joining

A joining node must do the following to join a CAN:

• Find an existing node in the overlay network.

• Choose a zone that can be divided.

• Update the routing tables of nodes in the newly divided zone's immediate vicinity.

• Bootstrapping nodes may be used to inform the joining node of IP addresses of nodes already in the overlay
network in order to find a node that is already in the overlay network.

After receiving an IP address from a node already in the CAN, the joining node can try to find a zone for itself.
The joining node selects a random point in the coordinate space and sends a join request to one of the
incoming IP addresses, which is directed to the random point. The join request is routed to the relevant
device via the zone-to-IP routing tables of the nodes already in the overlay network. When the node in
charge of the destination point's zone receives the join request, it can honor it by splitting its zone in half,
distributing the first half to itself and the second half to the joining node. If the joining node does not honor
the join request, it will continue to pick random points in the coordinate space and issue join requests to
these random places until it joins the network successfully.

The adjacent nodes are updated with the coordinates of the two new zones and the related IP addresses
after the zone split and allocation is completed. The routing tables are updated, and the changes are
broadcast throughout the network.
Node departing

The CAN must deal with a node that is leaving.

• detect a node that is leaving the network

• merge or take over the departing node's zone with a neighbouring node

• update the routing tables across the network

A node's departure can be detected using heartbeat messages, which broadcast routing table information to
neighbors on a regular basis. After a certain amount of calm, an adjacent node is assessed to be failed and is
termed a departing node. On the other side, a node that is willingly departing may broadcast such a message
to its neighbors.

The zone of a departing node must be merged or taken over after it has been detected. The zone of the
departed node is first examined to see if the zone of a neighboring node can be combined with the departed
node's zone to generate a valid zone. In a 2d coordinate space, for example, a zone must be square or
rectangle-shaped and cannot be L-shaped. To establish if a successful fusion is possible, the validation test
may cycle across all bordering zones. The zones are merged if one of the proposed merges is found to be
genuine. If none of the proposed mergers are found to be genuine, the departing node's zone is taken over
by the neighboring node with the smallest zone. Following a takeover, the takeover node may attempt to
integrate its additional controlled zones with nearby zones on a regular basis. If the merge is successful,
nearby zone node routing tables are modified to reflect the merge. After a merge, the network will treat the
portion of the overlay network as a single zone and treat all routing processing accordingly. To complete a
takeover, the take-over node modifies the routing tables of nearby zones' nodes, causing requests to either
zone to resolve to the take-over node. As a result, the network still recognizes the overlay network's part as
two different zones and treats all routing procedures accordingly.