/[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.159 by hemppah, Thu Mar 20 08:14:20 2003 UTC revision 1.160 by hemppah, Thu Mar 20 08:22:50 2003 UTC
# Line 188  directory, and had a single point of fai Line 188  directory, and had a single point of fai
188    
189  \section{Loosely structured}  \section{Loosely structured}
190    
191    
192  Gnutella \cite{gnutellaurl} is a well-known example of loosely structured overlay network. Gnutella  Gnutella \cite{gnutellaurl} is a well-known example of loosely structured overlay network. Gnutella
193  is a pure Peer-to-Peer network as no peer is more important than any other peer in the network.  is a pure Peer-to-Peer network as no peer is more important than any other peer in the network.
194  The construction and maintenance of Gnutella network is extremely ad hoc, since participating  The construction and maintenance of Gnutella network is extremely ad hoc, since participating
# Line 273  these peers to bear the load of the enti Line 274  these peers to bear the load of the enti
274  Previously presented improvements are only partial solutions. More advanced techniques  Previously presented improvements are only partial solutions. More advanced techniques
275  to improve data lookup of loosely structured systems are discussed in chapter 3.  to improve data lookup of loosely structured systems are discussed in chapter 3.
276    
   
277  \subsection{Sketch of a formal definition}  \subsection{Sketch of a formal definition}
278    
279  In this subsection we formalize loosely structured overlay's main components. This  In this subsection we formalize loosely structured overlay's main components. This
# Line 288  and $\forall$ regular peer $p$, and has Line 288  and $\forall$ regular peer $p$, and has
288  peer's content, specifically $sp$, $P$ = \{$p \in P: \exists sp$,  peer's content, specifically $sp$, $P$ = \{$p \in P: \exists sp$,
289  where $sp$ = $\delta(\gamma(\delta(s))) \wedge (p = \delta(s))$\}  where $sp$ = $\delta(\gamma(\delta(s))) \wedge (p = \delta(s))$\}
290    
   
291  \section{Tightly structured}  \section{Tightly structured}
292    
293  Partly due to scalability problems of loosely structured systems, several tightly  Partly due to scalability problems of loosely structured systems, several tightly
# Line 314  and Viceroy \cite{malkhi02viceroy} use a Line 313  and Viceroy \cite{malkhi02viceroy} use a
313  value of $n$ varies among systems. Again, CAN \cite{ratnasamy01can} uses a $d$-dimensional Cartesian  value of $n$ varies among systems. Again, CAN \cite{ratnasamy01can} uses a $d$-dimensional Cartesian
314  model to implement identifier space.  model to implement identifier space.
315    
316    There are three higher level abstractions which tightly structured overlays provide
317    \cite{zhao03api}. Each of these abstractions fulfill a storage layer in an overlay, but
318    they have semantical differences in the \emph{usage} of overlay. First, Distributed Hash
319    Table (DHT) (see e.g., \cite{dabek01widearea}, \cite{rowstron01storage}),  
320    implements three operations: \texttt{lookup(key)}, \texttt{remove(key)} and
321    \texttt{insert(key)}. As the name suggests, DHT implements the same functionality
322    as a regular hash table, by storing the mapping between a key and a value. DHT's
323    \emph{interface} is generic; values can be any size and type. Figure \ref{fig:Structured_lookup_using_DHT_model}
324    shows the DHT abstraction of the tightly structured overlay. Second, Decentralized
325    Object Location (DOLR) (see e.g., \cite{kubiatowicz00oceanstore}, \cite{iyer02squirrel}) is a distributed
326    directory service. DOLR stores \emph{pointers} to data items throughout the overlay. DOLR's main
327    operations are \texttt{publish(key)}, \texttt{removePublished(key)} and \texttt{sendToObject(key)}. The key
328    difference between DHT and DOLR abstraction is that DOLR routes overlay's messages
329    to nearest available peer, hosting a specific data item. This form of locality
330    is not supported by DHT. Finally, tightly structured overlay can be used for
331    scalable group multicast/any cast operations (CAST) (see e.g., \cite{zhuang01bayeux}).
332    The basic operations are \texttt{join(groupIdentifier)}, \texttt{leave(groupIdentifier)},
333    \texttt{multicast(message, groupIdentifier)},  \texttt{anycast(message, groupIdentifier)}.
334    Participating peers may join and leave the group and send multicast messages to
335    the group, or anycast message to a specific member of the group. DOLR and CAST abstractions
336    have in common that they both use network proximity techniques
337    to optimize their operations in the overlay. Figure \ref{fig:Strucutred_lookup_using_DOLR_model}
338    presents the DOLR abstraction.
339    
340    \begin{figure}
341    \centering
342    \includegraphics[width=10cm, height=7cm]{DHT_lookup.eps}
343    \caption{Distributed Hash Table (DHT) abstraction of tightly structured overlay.}
344    \label{fig:Structured_lookup_using_DHT_model}
345    \end{figure}
346    
347    
348    \begin{figure}
349    \centering
350    \includegraphics[width=10cm, height=7cm]{DOLR_lookup.eps}
351    \caption{Decentralized Object Location (DOLR) abstraction of tightly structured overlay.}
352    \label{fig:Strucutred_lookup_using_DOLR_model}
353    \end{figure}
354    
355  To store data into a tightly structured overlay, each application-specific  To store data into a tightly structured overlay, each application-specific
356  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
357  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 331  process of data to key mapping in a tigh Line 369  process of data to key mapping in a tigh
369  \label{fig:structured_hashing}  \label{fig:structured_hashing}
370  \end{figure}  \end{figure}
371    
372    Balakrishnan et al. \cite{balakrishanarticle03lookupp2p} which have to be
373    addressed in order to perform efficient data lookups in tightly structured overlays.
374    First, mapping of keys to peers must be done in a load-balanced
375    way. Second, the overlay must be able to forward a lookup for a
376    specific key to an appropriate peer. Third, overlay must have
377    support for a efficient distance function. Finally,  routing tables for each peer
378    must be constructed and maintained adaptively.
379    
380    Currently, all proposed tightly structured overlays provide at least
381    poly--logarithmical data lookup operations. However, there are some key
382    differences in the data structure that they use as a routing table. For example, Chord
383    \cite{stoica01chord}, Skip graphs \cite{AspnesS2003} and SkipNet \cite{harvey03skipnet2} maintain a local
384    data structure which resembles Skip lists \cite{78977}.
385    In figure \ref{fig:structured_query}, we present an overview of Chord's lookup process.
386    On the right side of Chord's lookup process, the same data lookup process
387    is shown as a binary-tree abstraction.  It can be noticed, that in each step, the distance
388    decreases with a logarithmic efficiency.
389    
390    \begin{figure}
391    \centering
392    \includegraphics[width=10cm, height=6cm]{structured_query.eps}
393    \caption{Chord's simplified data lookup process on top of tightly structured overlay.}
394    \label{fig:structured_query}
395    \end{figure}
396    
397    
398  All messages are routed across the overlay towards peers, whose  All messages are routed across the overlay towards peers, whose
399  peer identifier is gradually ''closer'' to the key's identifier  peer identifier is gradually ''closer'' to the key's identifier
400  in the identifier space. The distance can be measured by numerical  in the identifier space. The distance can be measured by numerical
# Line 365  as other tightly structured overlays, i. Line 429  as other tightly structured overlays, i.
429  for maintaining information about other peers in the system and  for maintaining information about other peers in the system and
430  $O(\log{n})$ data lookup efficiency.  $O(\log{n})$ data lookup efficiency.
431    
 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.  
   
 Currently, all proposed tightly structured overlays provide at least  
 poly--logarithmical data lookup operations. However, there are some key  
 differences in the data structure that they use as a routing table. For example, Chord  
 \cite{stoica01chord}, Skip graphs \cite{AspnesS2003} and SkipNet \cite{harvey03skipnet2} maintain a local  
 data structure which resembles Skip lists \cite{78977}.  
 In figure \ref{fig:structured_query}, we present an overview of Chord's lookup process.  
 On the right side of Chord's lookup process, the same data lookup process  
 is shown as a binary-tree abstraction.  It can be noticed, that in each step, the distance  
 decreases with a logarithmic efficiency.  
   
432  Kademlia \cite{maymounkov02kademlia}, Pastry \cite{rowston01pastry} and Tapestry  Kademlia \cite{maymounkov02kademlia}, Pastry \cite{rowston01pastry} and Tapestry
433  \cite{zhao01tapestry} uses balanced $k$-trees as routing table's data structure. Figure  \cite{zhao01tapestry} uses balanced $k$-trees as routing table's data structure. Figure
434  \ref{fig:kademlia_lookup} shows the process of Kademlia's  \ref{fig:kademlia_lookup} shows the process of Kademlia's
# Line 392  efficiency. Koorde \cite{kaashoek03koord Line 438  efficiency. Koorde \cite{kaashoek03koord
438  \cite{debruijn46graph} to maintain local routing tables. Koorde \cite{kaashoek03koorde} requires  \cite{debruijn46graph} to maintain local routing tables. Koorde \cite{kaashoek03koorde} requires
439  each peer to have only about two links to other peers to provide $O(\log{n})$ performance.  each peer to have only about two links to other peers to provide $O(\log{n})$ performance.
440    
 \begin{figure}  
 \centering  
 \includegraphics[width=10cm, height=6cm]{structured_query.eps}  
 \caption{Chord's simplified data lookup process on top of tightly structured overlay.}  
 \label{fig:structured_query}  
 \end{figure}  
   
441    
442  \begin{figure}  \begin{figure}
443  \centering  \centering
# Line 408  each peer to have only about two links t Line 447  each peer to have only about two links t
447  \end{figure}  \end{figure}
448    
449    
 There are three higher level abstractions which tightly structured overlays provide  
 \cite{zhao03api}. Each of these abstractions fulfill a storage layer in an overlay, but  
 they have semantical differences in the \emph{usage} of overlay. First, Distributed Hash  
 Table (DHT) (see e.g., \cite{dabek01widearea}, \cite{rowstron01storage}),    
 implements three operations: \texttt{lookup(key)}, \texttt{remove(key)} and  
 \texttt{insert(key)}. As the name suggests, DHT implements the same functionality  
 as a regular hash table, by storing the mapping between a key and a value. DHT's  
 \emph{interface} is generic; values can be any size and type. Figure \ref{fig:Structured_lookup_using_DHT_model}  
 shows the DHT abstraction of the tightly structured overlay. Second, Decentralized  
 Object Location (DOLR) (see e.g., \cite{kubiatowicz00oceanstore}, \cite{iyer02squirrel}) is a distributed  
 directory service. DOLR stores \emph{pointers} to data items throughout the overlay. DOLR's main  
 operations are \texttt{publish(key)}, \texttt{removePublished(key)} and \texttt{sendToObject(key)}. The key  
 difference between DHT and DOLR abstraction is that DOLR routes overlay's messages  
 to nearest available peer, hosting a specific data item. This form of locality  
 is not supported by DHT. Finally, tightly structured overlay can be used for  
 scalable group multicast/any cast operations (CAST) (see e.g., \cite{zhuang01bayeux}).  
 The basic operations are \texttt{join(groupIdentifier)}, \texttt{leave(groupIdentifier)},  
 \texttt{multicast(message, groupIdentifier)},  \texttt{anycast(message, groupIdentifier)}.  
 Participating peers may join and leave the group and send multicast messages to  
 the group, or anycast message to a specific member of the group. DOLR and CAST abstractions  
 have in common that they both use network proximity techniques  
 to optimize their operations in the overlay. Figure \ref{fig:Strucutred_lookup_using_DOLR_model}  
 presents the DOLR abstraction.  
   
 \begin{figure}  
 \centering  
 \includegraphics[width=10cm, height=7cm]{DHT_lookup.eps}  
 \caption{Distributed Hash Table (DHT) abstraction of tightly structured overlay.}  
 \label{fig:Structured_lookup_using_DHT_model}  
 \end{figure}  
   
   
 \begin{figure}  
 \centering  
 \includegraphics[width=10cm, height=7cm]{DOLR_lookup.eps}  
 \caption{Decentralized Object Location (DOLR) abstraction of tightly structured overlay.}  
 \label{fig:Strucutred_lookup_using_DOLR_model}  
 \end{figure}  
450    
451    
452  \subsection{Sketch of a formal definition}  \subsection{Sketch of a formal definition}

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

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