/[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.200 by hemppah, Thu Mar 27 14:20:37 2003 UTC revision 1.201 by hemppah, Tue Apr 8 09:25:03 2003 UTC
# Line 138  participants of Peer-to-Peer network sha Line 138  participants of Peer-to-Peer network sha
138  This is a form of distributed file system (e.g., \cite{levy90distributedfilesystems}).  This is a form of distributed file system (e.g., \cite{levy90distributedfilesystems}).
139  A modern Peer-to-Peer system is composed of an \emph{application} level overlay network, i.e.,  A modern Peer-to-Peer system is composed of an \emph{application} level overlay network, i.e.,
140  network operates at the application level and forms a logical network overlay on top of physical  network operates at the application level and forms a logical network overlay on top of physical
141  network. Figure \ref{fig:application_level} illustrates the Peer-to-Peer application level overlay network.  network with regard to the ISO-OSI reference model (e.g., \cite{800902}). Figure \ref{fig:application_level}
142    illustrates the Peer-to-Peer application level overlay network.
143  Compared to ARPANET's Peer-to-Peer functionality, modern Peer-to-Peer systems  Compared to ARPANET's Peer-to-Peer functionality, modern Peer-to-Peer systems
144  are \emph{ad hoc}, i.e., peers join and leave the system constantly. Thus, this property  are \emph{ad hoc}, i.e., peers join and leave the system constantly. Thus, this property
145  poses challenges for efficient construction and maintenance  poses challenges for efficient construction and maintenance
# Line 178  loosely. The placement of services and t Line 179  loosely. The placement of services and t
179  not very efficient, because of unstructured properties of the overlay. Data lookup model is a combination of methods which  not very efficient, because of unstructured properties of the overlay. Data lookup model is a combination of methods which
180  are used for locating data in the overlay.    are used for locating data in the overlay.  
181    
182  \subsection{Definition}  \subsection{Skecth of definition}
183    
184  In this subsection we formalize loosely structured overlay's main components. This  In this subsection, we try to introduce a \emph{sketch} of formal definition of the loosely structured overlay. This
185  model is based on original Gnutella overlay network with power-law improvements.  model is based on original Gnutella overlay network with power-law improvements.
186    
187  Let $S$ be the aggregate of all services $s$ in system. Let $P$ be the aggregate of  Let $S$ be the aggregate of all services $s$ in system. Let $P$ be the aggregate of
# Line 200  people to share music. It was a hybrid P Line 201  people to share music. It was a hybrid P
201  index was centralized and the distribution of storage and serving of files was distributed.  index was centralized and the distribution of storage and serving of files was distributed.
202  Peers in the Napster network made requests to the central directory server to find  Peers in the Napster network made requests to the central directory server to find
203  other peers hosting desirable content. Since service requests were totally based on a  other peers hosting desirable content. Since service requests were totally based on a
204  centralized index, Napster didn't scale well because of constantly updated central  centralized index, Napster didn't scale 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 system. 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.
# Line 297  overlay and the placement of services is Line 298  overlay and the placement of services is
298    
299  \subsection{Definition}  \subsection{Definition}
300    
301  In this subsection, we formalize the main features of tightly structured overlay such as  In this subsection, we try to introduce a \emph{sketch} of formal definition of the tightly structured overlay, such as
302  identifiers, identifier space and the mapping function.  identifiers, identifier space and the mapping function.
303    
304  Let $S$ be the aggregate of all services $s$ in the system. Let $P$ be the aggregate of  Let $S$ be the aggregate of all services $s$ in the system. Let $P$ be the aggregate of
# Line 315  where $\theta(p,p_n)$ = ''close'', and ' Line 316  where $\theta(p,p_n)$ = ''close'', and '
316  \subsection{Systems}  \subsection{Systems}
317    
318  With tightly structured systems, it is feasible to perform \emph{global} data lookups in the overlay efficiently. By global lookup, we mean  With tightly structured systems, it is feasible to perform \emph{global} data lookups in the overlay efficiently. By global lookup, we mean
319  that the system is able to find a service from the overlay, if it exists in the overlay.  that the system is able to find a service from the overlay, if it exists.
320  While there are significant differences among proposed tightly structured systems, they all have in common  While there are significant differences among proposed tightly structured systems, they all have in common
321  that \emph{peer identifiers} are assigned to participating peers from  that \emph{peer identifiers} are assigned to participating peers from
322  a large \emph{identifier space} by the overlay. Globally unique identifiers  a large \emph{identifier space} by the overlay. Globally unique identifiers
# Line 331  model to implement the form of identifie Line 332  model to implement the form of identifie
332    
333  To store data into a tightly structured overlay, each application-specific  To store data into a tightly structured overlay, each application-specific
334  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
335  hashing \cite{258660}) by the overlay to an existing peer in the overlay. Thus, tightly  hashing \cite{258660}) to an existing peer in the overlay. Thus, tightly
336  structured overlay assigns a subset of all possible keys to every participating peer.  structured overlay assigns a subset of all possible keys to every participating peer.
337  We say that a peer is \emph{responsible} for the keys which are assigned by the overlay.  We say that a peer is \emph{responsible} for the keys which are assigned by the overlay.
338  Figure \ref{fig:structured_hashing} illustrates this  Figure \ref{fig:structured_hashing} illustrates this
# Line 364  decreases with a logarithmic efficiency. Line 365  decreases with a logarithmic efficiency.
365  \end{figure}  \end{figure}
366    
367  Kademlia \cite{maymounkov02kademlia}, Pastry \cite{rowston01pastry} and Tapestry  Kademlia \cite{maymounkov02kademlia}, Pastry \cite{rowston01pastry} and Tapestry
368  \cite{zhao01tapestry} uses balanced $k$-trees to implement the data structure of identifier space. Figure  \cite{zhao01tapestry} use balanced $k$-trees to implement the data structure of the identifier space. Figure
369  \ref{fig:kademlia_lookup} shows the process of Kademlia's  \ref{fig:kademlia_lookup} shows the process of Kademlia's
370  data lookup. Viceroy \cite{malkhi02viceroy} maintains a butterfly data structure (e.g., \cite{226658}),  data lookup. Viceroy \cite{malkhi02viceroy} maintains a butterfly data structure (e.g., \cite{226658}),
371  which requires only a constant number of neighbor peers while providing $O(\log{n})$ data lookup  which requires only a constant number of neighbor peers while providing $O(\log{n})$ data lookup
372  efficiency. Koorde \cite{kaashoek03koorde}, a recent modification of Chord, uses de Bruijn graphs  efficiency. Koorde \cite{kaashoek03koorde}, a recent modification of Chord, uses de Bruijn graphs
373  \cite{debruijn46graph} to maintain local routing tables. Koorde \cite{kaashoek03koorde} requires  \cite{debruijn46graph} to maintain local routing tables. It requires
374  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.
375    
376    
# Line 380  each peer to have only about two links t Line 381  each peer to have only about two links t
381  \label{fig:kademlia_lookup}  \label{fig:kademlia_lookup}
382  \end{figure}  \end{figure}
383    
384  Currently, there are only three higher level abstractions which tightly structured overlays provide  Currently, there are only three higher level abstractions which are provided by the tightly structured overlays
385  \cite{zhao03api}. Each of these abstractions represent a storage layer in the overlay, but  \cite{zhao03api}. Each of these abstractions represent a storage layer in the overlay, but
386  have semantical differences in the \emph{usage} of the overlay.  have semantical differences in the \emph{usage} of the overlay.
387    
# Line 408  operations are: Line 409  operations are:
409  \end{itemize}  \end{itemize}
410    
411    
412  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.  The key difference between the DHT and the DOLR abstraction is that in the DOLR abstraction the overlay maintains only \emph{pointers} to the data.
413  Also, the DOLR abstraction routes overlay's messages to a nearest available peer, hosting a specific data item. This form of locality  Also, the DOLR abstraction routes overlay's messages to a nearest available peer, hosting a specific data item. This form of locality
414  is not supported by DHT. DOLR's interface is similar to the DHT's interface, i.e., values can be any size and type.  is not supported by DHT. DOLR's interface is similar to the DHT's interface, i.e., values can be any size and type.
415    
# Line 454  Chord's \cite{stoica01chord} distance fu Line 455  Chord's \cite{stoica01chord} distance fu
455  is exactly one point $p_j$ in a way that the distance between $p_i$ and $p_j$  is exactly one point $p_j$ in a way that the distance between $p_i$ and $p_j$
456  is $d$), but doesn't have symmetry (the distance from $p_i$ to $p_j$ is same as the  is $d$), but doesn't have symmetry (the distance from $p_i$ to $p_j$ is same as the
457  distance from $p_j$ to $p_i$). Pastry's \cite{rowston01pastry} distance function supports  distance from $p_j$ to $p_i$). Pastry's \cite{rowston01pastry} distance function supports
458  symmetry, but doesn't support unidirection. Because of XOR-metric, Kademlia's distance  symmetry, but doesn't support unidirection. According to \cite{balakrishanarticle03lookupp2p}, because
459  function is both unidirectional and symmetric. Moreover, Kademlia's \cite{maymounkov02kademlia}  of XOR-metric, Kademlia's distance function is both unidirectional and symmetric. Moreover, Kademlia's \cite{maymounkov02kademlia}
460  XOR-based metric doesn't need stabilization (like in Chord \cite{stoica01chord}) and backup links  XOR-based metric doesn't need stabilization (like in Chord \cite{stoica01chord}) and backup links
461  (like in Pastry \cite{rowston01pastry}) \cite{balakrishanarticle03lookupp2p}.  (like in Pastry \cite{rowston01pastry}).
462  However, in all above schemes each hop in the overlay shortens the distance between  However, in all above schemes each hop in the overlay shortens the distance between
463  current peer working with the data lookup and the key which was looked up in the identifier space.  current peer working with the data lookup and the key which was looked up in the identifier space.
464    

Legend:
Removed from v.1.200  
changed lines
  Added in v.1.201

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