210 |
|
|
211 |
\section{Distributed Hash Tables} |
\section{Distributed Hash Tables} |
212 |
|
|
213 |
In DHT approach, each value is associated with a key in an m-bit virtual address space. The virtual |
In DHT approach, each value is associated with a unique key (e.g. SHA-1 \cite{fips-sha-1})in an m-bit virtual address space. The virtual |
214 |
address space is partitioned into sections, which form adjoining regions of this address space. In general, |
address space is partitioned into sections, which form adjoining regions of this address space. In general, |
215 |
either a single computer or multiple computers is assigned to each section of the virtual address space. Each |
either a single computer or multiple computers is assigned to each section of the virtual address space. Each |
216 |
computer is assigned one or more sections, and they maintains copies of those key-value bindings whose key values |
computer is assigned one or more sections, and they maintains copies of those key-value bindings whose key values |
217 |
lie within its assigned cell. This means, in general, that computer that hosts corresponding key-value pair, |
lie within its assigned cell. This means, in general, that computer that hosts corresponding key-value pair, |
218 |
is not owned by the user that decided to provide the resource to the community. Moreover, the allocation of the address |
is not owned by the user that decided to provide the resource to the netowork. Moreover, the allocation of the address |
219 |
space and the assigment of computers to sections is dynamic. Therefore, everytime when a node joins or |
space and the assigment of computers to sections is dynamic. Therefore, everytime when a node joins or |
220 |
leaves the network, the address space is reallocated. |
leaves the network, the address space is reallocated. |
221 |
|
|
222 |
|
|
|
|
|
223 |
\subsection{Plaxton Algorithm} |
\subsection{Plaxton Algorithm} |
224 |
Plaxton \cite{plaxton97accessingnearby} developed the first routing algorithm, which can be used with DHTs. |
Plaxton \cite{plaxton97accessingnearby} developed the first routing algorithm, which can be used with DHTs. |
225 |
The algorithm is not designed to be used in dynamic distributed systems, because Plaxton algorithm |
The algorithm is not designed to be used in dynamic distributed systems, because Plaxton algorithm |
262 |
Kademlia \cite{maymounkov02kademlia} is based on a XOR-based metric topology. In this approach, every query (message) exchanged conveys |
Kademlia \cite{maymounkov02kademlia} is based on a XOR-based metric topology. In this approach, every query (message) exchanged conveys |
263 |
useful contact information. Furthermore, Kademlia uses this information to send parallel query messages. XOR-metrics are used to calculate |
useful contact information. Furthermore, Kademlia uses this information to send parallel query messages. XOR-metrics are used to calculate |
264 |
distances between points in key space. XOR is symmetric, allowing nodes to receive lookup queries from the same distribution of nodes |
distances between points in key space. XOR is symmetric, allowing nodes to receive lookup queries from the same distribution of nodes |
265 |
contained in the key space. Routing table contains ''contact buckets'', which allows to accommodate temporarily used nodes more |
contained in the key space. Routing table contains ``contact buckets'', which allows to accommodate temporarily used nodes more |
266 |
efficiently than other DHT approaches. For a system with $n$ nodes, Kademlia's algorithm routes in $O(log n)$ hops and requires |
efficiently than other DHT approaches. For a system with $n$ nodes, Kademlia's algorithm routes in $O(log n)$ hops and requires |
267 |
a routing table size of $O(log n)$. |
a routing table size of $O(log n)$. |
268 |
|
|
269 |
|
\subsection{Coral} |
270 |
|
|
271 |
|
Coral [NOTYETPUBLISHED] is based on a new abstraction called distributed sloppy hash table (DSHT) and is a layer on existing |
272 |
|
lookup systems, such as Chord, CAN, Kademlia, Pastry and Tapestry. In contrast to original DHTs, Coral provides a lookup, which |
273 |
|
is based on name (instead of hash value). Furthermore, Coral aims to avoid DHTs' hot spots and to find nearby data without querying |
274 |
|
distant nodes. DSHTs sacrifice the consistency of DHTs to support both frequent fetches and frequent stores of the same hash table |
275 |
|
key. Moreover, the fundamental observation is that a node doesn't need to know every replicated location of a resource---it only |
276 |
|
needs a single nearby copy. |
277 |
|
|
278 |
\section{Gnutella} |
\section{Gnutella} |
279 |
\section{OceanStore} |
\section{OceanStore} |