/[gzz]/gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
ViewVC logotype

Diff of /gzz/Documentation/misc/hemppah-progradu/masterthesis.tex

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.20 by hemppah, Tue Dec 10 11:54:48 2002 UTC revision 1.21 by hemppah, Tue Dec 10 12:32:28 2002 UTC
# Line 210  In this section, we review briefly exist Line 210  In this section, we review briefly exist
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
# Line 263  hops. Additionally in Chord, a join or l Line 262  hops. Additionally in Chord, a join or l
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}

Legend:
Removed from v.1.20  
changed lines
  Added in v.1.21

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26