352 |
\label{fig:Strucutred_lookup_using_DOLR_model} |
\label{fig:Strucutred_lookup_using_DOLR_model} |
353 |
\end{figure} |
\end{figure} |
354 |
|
|
355 |
|
Balakrishnan et al. \cite{balakrishanarticle03lookupp2p} have listed four requirements |
356 |
|
for tightly structured overlays which have to be addressed in order |
357 |
|
to perform efficient data lookups in tightly structured overlays. |
358 |
|
First, mapping of keys to peers must be done in a load-balanced |
359 |
|
way. Second, the overlay must be able to forward a lookup for a |
360 |
|
specific key to an appropriate peer. Third, overlay must have |
361 |
|
support for a efficient distance function. Finally, routing tables for each peer |
362 |
|
must be constructed and maintained adaptively. |
363 |
|
|
364 |
To store data into a tightly structured overlay, each application-specific |
To store data into a tightly structured overlay, each application-specific |
365 |
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 |
366 |
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 |
378 |
\label{fig:structured_hashing} |
\label{fig:structured_hashing} |
379 |
\end{figure} |
\end{figure} |
380 |
|
|
|
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. |
|
|
|
|
381 |
Currently, all proposed tightly structured overlays provide at least |
Currently, all proposed tightly structured overlays provide at least |
382 |
poly--logarithmical data lookup operations. However, there are some key |
poly--logarithmical data lookup operations. However, there are some key |
383 |
differences in the data structure that they use as a routing table. For example, Chord |
differences in the data structure that they use as a routing table. For example, Chord |
395 |
\label{fig:structured_query} |
\label{fig:structured_query} |
396 |
\end{figure} |
\end{figure} |
397 |
|
|
398 |
|
Kademlia \cite{maymounkov02kademlia}, Pastry \cite{rowston01pastry} and Tapestry |
399 |
|
\cite{zhao01tapestry} uses balanced $k$-trees as routing table's data structure. Figure |
400 |
|
\ref{fig:kademlia_lookup} shows the process of Kademlia's |
401 |
|
data lookup. Viceroy \cite{malkhi02viceroy} maintains a butterfly data structure (e.g., \cite{226658}), |
402 |
|
which requires only a constant number of neighbor peers while providing $O(\log{n})$ data lookup |
403 |
|
efficiency. Koorde \cite{kaashoek03koorde}, a recent modification of Chord, uses de Bruijn graphs |
404 |
|
\cite{debruijn46graph} to maintain local routing tables. Koorde \cite{kaashoek03koorde} requires |
405 |
|
each peer to have only about two links to other peers to provide $O(\log{n})$ performance. |
406 |
|
|
407 |
|
|
408 |
|
\begin{figure} |
409 |
|
\centering |
410 |
|
\includegraphics[width=10cm, height=8cm]{kademlia_lookup.eps} |
411 |
|
\caption{Kademlia's simplified data lookup process on top of tightly structured overlay.} |
412 |
|
\label{fig:kademlia_lookup} |
413 |
|
\end{figure} |
414 |
|
|
415 |
|
|
416 |
All messages are routed across the overlay towards peers, whose |
All messages are routed across the overlay towards peers, whose |
417 |
peer identifier is gradually ''closer'' to the key's identifier |
peer identifier is gradually ''closer'' to the key's identifier |
447 |
for maintaining information about other peers in the system and |
for maintaining information about other peers in the system and |
448 |
$O(\log{n})$ data lookup efficiency. |
$O(\log{n})$ data lookup efficiency. |
449 |
|
|
|
Kademlia \cite{maymounkov02kademlia}, Pastry \cite{rowston01pastry} and Tapestry |
|
|
\cite{zhao01tapestry} uses balanced $k$-trees as routing table's data structure. Figure |
|
|
\ref{fig:kademlia_lookup} shows the process of Kademlia's |
|
|
data lookup. Viceroy \cite{malkhi02viceroy} maintains a butterfly data structure (e.g., \cite{226658}), |
|
|
which requires only a constant number of neighbor peers while providing $O(\log{n})$ data lookup |
|
|
efficiency. Koorde \cite{kaashoek03koorde}, a recent modification of Chord, uses de Bruijn graphs |
|
|
\cite{debruijn46graph} to maintain local routing tables. Koorde \cite{kaashoek03koorde} requires |
|
|
each peer to have only about two links to other peers to provide $O(\log{n})$ performance. |
|
|
|
|
|
|
|
|
\begin{figure} |
|
|
\centering |
|
|
\includegraphics[width=10cm, height=8cm]{kademlia_lookup.eps} |
|
|
\caption{Kademlia's simplified data lookup process on top of tightly structured overlay.} |
|
|
\label{fig:kademlia_lookup} |
|
|
\end{figure} |
|
|
|
|
|
|
|
|
|
|
450 |
|
|
451 |
\subsection{Sketch of a formal definition} |
\subsection{Sketch of a formal definition} |
452 |
|
|