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))$\} |
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} |
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 |
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 |