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