/[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.169 by hemppah, Fri Mar 21 13:34:14 2003 UTC revision 1.170 by hemppah, Fri Mar 21 14:48:14 2003 UTC
# Line 188  Let $S$ be the aggregate of all services Line 188  Let $S$ be the aggregate of all services
188  all peers $p$ in system. Then, $\forall s \in S$, there is a provider of the service,  all peers $p$ in system. Then, $\forall s \in S$, there is a provider of the service,
189  expressed as $p = \delta(s)$. Every $p$ has neighbor(s), named as $p_n$, which  expressed as $p = \delta(s)$. Every $p$ has neighbor(s), named as $p_n$, which
190  is $P$ = \{$p \in P: \exists neighbor$, which is randomly chosen from $P$\}.  is $P$ = \{$p \in P: \exists neighbor$, which is randomly chosen from $P$\}.
191  Summary index maintains indices of other peers, $si = \gamma(\delta(s))$.  Summary index maintains indices of other peers, $si o= \gamma(\delta(s))$.
192  Then, $\forall$ regular peer $p$, there is a super peer, $sp$, and it has a index of  Then, $\forall$ regular peer $p$, there is a super peer, $sp$, and it has a index of
193  regular peer's content $P$ = \{$p \in P: \exists sp$,  regular peer's content $P$ = \{$p \in P: \exists sp$,
194  where $sp$ = $\delta(\gamma(\delta(s))) \wedge (p = \delta(s))$\}  where $sp$ = $\delta(\gamma(\delta(s))) \wedge (p = \delta(s))$\}
# Line 204  other peers hosting desirable content. S Line 204  other peers hosting desirable content. S
204  centralized index, Napster didn't scale well because of constantly updated central  centralized index, Napster didn't scale well because of constantly updated central
205  directory, and had a single point of failure.  directory, and had a single point of failure.
206    
207  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 system. Gnutella
208  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.
209  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
210  peers can form the overlay network based on \emph{local} knowledge. Figure \ref{fig:gnutella_overlay}  peers can form the overlay network based on \emph{local} knowledge. Figure \ref{fig:gnutella_overlay}
# Line 320  it is now feasible to perform \emph{glob Line 320  it is now feasible to perform \emph{glob
320  that the system is able to find a service from the overlay efficiently, if it exists in the overlay.  that the system is able to find a service from the overlay efficiently, if it exists in the overlay.
321  While there are significant differences among proposed tighty structured systems, they all have in common  While there are significant differences among proposed tighty structured systems, they all have in common
322  that \emph{peer identifiers} are assigned to participating peers from  that \emph{peer identifiers} are assigned to participating peers from
323  a large \emph{identifier space} by the overlay. Furthermore, globally unique identifiers  a large \emph{identifier space} by the overlay. Globally unique identifiers
324  are also assigned to application-specific data items, \emph{keys},  are also assigned to application-specific data items, \emph{keys},
325  which are selected from the same identifier space. The form of identifier  which are selected from the same identifier space. For instance, globally unique keys can be created
326  space differs between proposed systems. Circular identifier space (and variants)  using a cryptographic content hash (e.g., \cite{fips-sha-1}) over the contents of a data item.
327    The form of identifier space differs between proposed systems. Geometrical circular form of identifier space (and variants)
328  is most widely used. For instance, Chord \cite{stoica01chord}, Koorde \cite{kaashoek03koorde},  is most widely used. For instance, Chord \cite{stoica01chord}, Koorde \cite{kaashoek03koorde},
329  Pastry \cite{rowston01pastry}, SWAN \cite{bonsma02swan}, Tapestry \cite{zhao01tapestry}  Pastry \cite{rowston01pastry}, SWAN \cite{bonsma02swan}, Tapestry \cite{zhao01tapestry}
330  and Viceroy \cite{malkhi02viceroy} use a circular identifier space of $n$-bit integers modulo $2^{n}$. The  and Viceroy \cite{malkhi02viceroy} use a circular form of identifier space of $n$-bit integers modulo $2^{n}$. The
331  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 geometrical torus
332  model to implement the identifier space.  model to implement the form of identifier space.
   
 There are three higher level abstractions which tightly structured overlays provide  
 \cite{zhao03api}. Each of these abstractions fulfill a storage layer in the overlay, but  
 have semantical differences in the \emph{usage} of the 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 the DHT and the DOLR abstraction is that the DOLR abstraction routes overlay's messages  
 to a 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 or anycast 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. The DOLR and the 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}  
333    
334    To store data into a tightly structured overlay, each application-specific
335    unique key (e.g., SHA-1 \cite{fips-sha-1}) is \emph{mapped} uniformly (e.g., using consistent
336    hashing \cite{258660}) by the overlay to an existing peer in the overlay. Thus, tightly
337    structured overlay assigns a subset of all possible keys to every participating peer.
338    We say that a peer is \emph{responsible} for the keys which are assigned by the overlay.
339    Figure \ref{fig:structured_hashing} illustrates the
340    process of data to key mapping in a tightly structured overlay.  
341    Also, each peer in the tightly structured overlay maintains a \emph{routing table}, which
342    consists of identifiers and IP addresses of other peers in the overlay. Entries of the routing
343    table represent peer's neighbors in the overlay network.
344    
345  \begin{figure}  \begin{figure}
346  \centering  \centering
347  \includegraphics[width=10cm, height=7cm]{DOLR_lookup.eps}  \includegraphics[width=12cm, height=7cm]{structured_overlay_new.eps}
348  \caption{Decentralized Object Location (DOLR) abstraction of tightly structured overlay.}  \caption{Principal idea of tightly structured overlays.}
349  \label{fig:Strucutred_lookup_using_DOLR_model}  \label{fig:structured_hashing}
350  \end{figure}  \end{figure}
351    
352  Balakrishnan et al. \cite{balakrishanarticle03lookupp2p} have listed four requirements  Balakrishnan et al. \cite{balakrishanarticle03lookupp2p} have listed four requirements
# Line 378  specific key to an appropriate peer. Thi Line 358  specific key to an appropriate peer. Thi
358  support efficient distance function. Finally,  routing tables for each peer  support efficient distance function. Finally,  routing tables for each peer
359  must be constructed and maintained adaptively.  must be constructed and maintained adaptively.
360    
361  To store data into a tightly structured overlay, each application-specific  Currently, there are only three higher level abstractions which tightly structured overlays provide
362  unique key (e.g., SHA-1 \cite{fips-sha-1}) is \emph{mapped} uniformly (e.g., using consistent  \cite{zhao03api}. Each of these abstractions represent a storage layer in the overlay, but
363  hashing \cite{258660}) by the overlay to an existing peer in the overlay. Thus, tightly  have semantical differences in the \emph{usage} of the overlay.
364  structured overlay assigns a subset of all possible keys to every participating peer.  
365  We say that a peer is \emph{responsible} for the keys which are assigned by the overlay.  First, Distributed Hash Table (DHT) (see e.g., \cite{dabek01widearea}, \cite{rowstron01storage}),  
366  Figure \ref{fig:structured_hashing} illustrates the  implements the same functionality as a regular hash table by storing the mapping between a key and a value:
367  process of data to key mapping in a tightly structured overlay.    
368  Also, each peer in the tightly structured overlay maintains a \emph{routing table}, which  \begin{itemize}
369  consists of identifiers and IP addresses of other peers in the overlay. Entries of the routing  \item \texttt{lookup(key)}: perform a data lookup with a given key.
370  table represent peer's neighbors in the overlay network.  \item \texttt{insert(key)}: insert a data item with a given key.
371    \item \texttt{remove(key)}: remove a data item with a given key.
372    \end{itemize}
373    
374    DHT's \emph{interface} is generic; values can be any size and type (e.g., content hash over a file or IP address). In the
375    DHT abstraction, the overlay itself stores the data items. Figure \ref{fig:Structured_lookup_using_DHT_model} shows the DHT abstraction
376    of the tightly structured overlay.
377    
378    Second, Decentralized Object Location (DOLR) (see e.g., \cite{kubiatowicz00oceanstore}, \cite{iyer02squirrel}) is a distributed
379    directory service. DOLR stores \emph{pointers} to data items throughout the overlay. DOLR's main
380    operations are:
381    
382    \begin{itemize}
383    \item \texttt{publish(key)}: announce availability of a data item.
384    \item \texttt{removePublished(key)}: remove a data item.
385    \item \texttt{sendToObject(key)}: deliver a data item to a nearby peer hosting the replica of data item.
386    \end{itemize}
387    
388    
389    The key difference between the DHT and the DOLR abstraction is that in the DOLR abstraction the overlay maintains only the \emph{pointers} to the data.
390    Also, the DOLR abstraction routes overlay's messages to a nearest available peer, hosting a specific data item. This form of locality
391    is not supported by DHT. DOLR's interface is similar to the DHT's interface, i.e., values can be any size and type
392    (e.g., content hash over a file or IP address).
393    
394    Third, tightly structured overlay can be used for scalable group multicast or anycast operations (CAST) (see e.g., \cite{zhuang01bayeux}).
395    The basic operations include:
396    
397    \begin{itemize}
398    \item \texttt{join(groupIdentifier)}: join to a group with a given group identifer.
399    \item \texttt{leave(groupIdentifier)}: leave a group with a given group identifier.
400    \item \texttt{multicast(message, groupIdentifier)}: multicast a message to a group with a given group identifier.
401    \item \texttt{anycast(message, groupIdentifier)}: anycast a message to a group with a given group identifier.
402    \end{itemize}
403    
404    The DOLR and the CAST abstractions have in common that they both use network proximity techniques
405    to optimize their operations in the overlay. Figure \ref{fig:Strucutred_lookup_using_DOLR_model}
406    presents the DOLR abstraction.
407    
408  \begin{figure}  \begin{figure}
409  \centering  \centering
410  \includegraphics[width=12cm, height=7cm]{structured_overlay_new.eps}  \includegraphics[width=10cm, height=7cm]{DHT_lookup.eps}
411  \caption{Principal idea of tightly structured overlays.}  \caption{Distributed Hash Table (DHT) abstraction of tightly structured overlay. In the
412  \label{fig:structured_hashing}  DHT abstraction a data item is located directly from the provider peer.}
413    \label{fig:Structured_lookup_using_DHT_model}
414    \end{figure}
415    
416    
417    \begin{figure}
418    \centering
419    \includegraphics[width=10cm, height=7cm]{DOLR_lookup.eps}
420    \caption{Decentralized Object Location (DOLR) abstraction of tightly structured overlay.
421    In the DOLR abstraction, a data item is located indirectly, using the pointer peer.}
422    \label{fig:Strucutred_lookup_using_DOLR_model}
423  \end{figure}  \end{figure}
424    
425  Currently, all proposed tightly structured overlays provide at least  Currently, all proposed tightly structured overlays provide at least
426  poly--logarithmical data lookup operations. However, there are some key  poly--logarithmical data lookup operations. However, there are some key
427  differences in the data structure that they use as a routing table. For example, Chord  differences in the data structures representing the identifier space.
428  \cite{stoica01chord}, Skip graphs \cite{AspnesS2003} and SkipNet \cite{harvey03skipnet2} maintain a  For example, Chord \cite{stoica01chord}, Skip graphs \cite{AspnesS2003} and SkipNet \cite{harvey03skipnet2} maintain a
429  distributed data structure which resembles Skip lists \cite{78977}.  distributed data structure which resembles Skip lists \cite{78977}.
430  In figure \ref{fig:structured_query}, we present an overview of Chord's lookup process.  In figure \ref{fig:structured_query}, we present an overview of Chord's lookup process.
431  On the right side of Chord's lookup process, the same data lookup process  On the right side of Chord's lookup process, the same data lookup process

Legend:
Removed from v.1.169  
changed lines
  Added in v.1.170

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