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 |
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 |
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. |
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 |
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 |
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 |
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|