/[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.160 by hemppah, Thu Mar 20 08:22:50 2003 UTC revision 1.161 by hemppah, Thu Mar 20 08:43:18 2003 UTC
# Line 352  presents the DOLR abstraction. Line 352  presents the DOLR abstraction.
352  \label{fig:Strucutred_lookup_using_DOLR_model}  \label{fig:Strucutred_lookup_using_DOLR_model}
353  \end{figure}  \end{figure}
354    
355    Balakrishnan et al. \cite{balakrishanarticle03lookupp2p} have listed four requirements
356    for tightly structured overlays which have to be addressed in order
357    to perform efficient data lookups in tightly structured overlays.
358    First, mapping of keys to peers must be done in a load-balanced
359    way. Second, the overlay must be able to forward a lookup for a
360    specific key to an appropriate peer. Third, overlay must have
361    support for a efficient distance function. Finally,  routing tables for each peer
362    must be constructed and maintained adaptively.
363    
364  To store data into a tightly structured overlay, each application-specific  To store data into a tightly structured overlay, each application-specific
365  unique key (e.g., SHA-1 \cite{fips-sha-1}) is \emph{mapped} uniformly (e.g., using consistent  unique key (e.g., SHA-1 \cite{fips-sha-1}) is \emph{mapped} uniformly (e.g., using consistent
366  hashing \cite{258660}) by the overlay to an existing peer in the overlay. Thus, tightly  hashing \cite{258660}) by the overlay to an existing peer in the overlay. Thus, tightly
# Line 369  process of data to key mapping in a tigh Line 378  process of data to key mapping in a tigh
378  \label{fig:structured_hashing}  \label{fig:structured_hashing}
379  \end{figure}  \end{figure}
380    
 Balakrishnan et al. \cite{balakrishanarticle03lookupp2p} which have to be  
 addressed in order to perform efficient data lookups in tightly structured overlays.  
 First, mapping of keys to peers must be done in a load-balanced  
 way. Second, the overlay must be able to forward a lookup for a  
 specific key to an appropriate peer. Third, overlay must have  
 support for a efficient distance function. Finally,  routing tables for each peer  
 must be constructed and maintained adaptively.  
   
381  Currently, all proposed tightly structured overlays provide at least  Currently, all proposed tightly structured overlays provide at least
382  poly--logarithmical data lookup operations. However, there are some key  poly--logarithmical data lookup operations. However, there are some key
383  differences in the data structure that they use as a routing table. For example, Chord  differences in the data structure that they use as a routing table. For example, Chord
# Line 394  decreases with a logarithmic efficiency. Line 395  decreases with a logarithmic efficiency.
395  \label{fig:structured_query}  \label{fig:structured_query}
396  \end{figure}  \end{figure}
397    
398    Kademlia \cite{maymounkov02kademlia}, Pastry \cite{rowston01pastry} and Tapestry
399    \cite{zhao01tapestry} uses balanced $k$-trees as routing table's data structure. Figure
400    \ref{fig:kademlia_lookup} shows the process of Kademlia's
401    data lookup. Viceroy \cite{malkhi02viceroy} maintains a butterfly data structure (e.g., \cite{226658}),
402    which requires only a constant number of neighbor peers while providing $O(\log{n})$ data lookup
403    efficiency. Koorde \cite{kaashoek03koorde}, a recent modification of Chord, uses de Bruijn graphs
404    \cite{debruijn46graph} to maintain local routing tables. Koorde \cite{kaashoek03koorde} requires
405    each peer to have only about two links to other peers to provide $O(\log{n})$ performance.
406    
407    
408    \begin{figure}
409    \centering
410    \includegraphics[width=10cm, height=8cm]{kademlia_lookup.eps}
411    \caption{Kademlia's simplified data lookup process on top of tightly structured overlay.}
412    \label{fig:kademlia_lookup}
413    \end{figure}
414    
415    
416  All messages are routed across the overlay towards peers, whose  All messages are routed across the overlay towards peers, whose
417  peer identifier is gradually ''closer'' to the key's identifier  peer identifier is gradually ''closer'' to the key's identifier
# Line 429  as other tightly structured overlays, i. Line 447  as other tightly structured overlays, i.
447  for maintaining information about other peers in the system and  for maintaining information about other peers in the system and
448  $O(\log{n})$ data lookup efficiency.  $O(\log{n})$ data lookup efficiency.
449    
 Kademlia \cite{maymounkov02kademlia}, Pastry \cite{rowston01pastry} and Tapestry  
 \cite{zhao01tapestry} uses balanced $k$-trees as routing table's data structure. Figure  
 \ref{fig:kademlia_lookup} shows the process of Kademlia's  
 data lookup. Viceroy \cite{malkhi02viceroy} maintains a butterfly data structure (e.g., \cite{226658}),  
 which requires only a constant number of neighbor peers while providing $O(\log{n})$ data lookup  
 efficiency. Koorde \cite{kaashoek03koorde}, a recent modification of Chord, uses de Bruijn graphs  
 \cite{debruijn46graph} to maintain local routing tables. Koorde \cite{kaashoek03koorde} requires  
 each peer to have only about two links to other peers to provide $O(\log{n})$ performance.  
   
   
 \begin{figure}  
 \centering  
 \includegraphics[width=10cm, height=8cm]{kademlia_lookup.eps}  
 \caption{Kademlia's simplified data lookup process on top of tightly structured overlay.}  
 \label{fig:kademlia_lookup}  
 \end{figure}  
   
   
   
450    
451  \subsection{Sketch of a formal definition}  \subsection{Sketch of a formal definition}
452    

Legend:
Removed from v.1.160  
changed lines
  Added in v.1.161

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