167 |
overlay network. |
overlay network. |
168 |
|
|
169 |
In the end, however, we observe that there are only two approaches in which all modern Peer-to-Peer |
In the end, however, we observe that there are only two approaches in which all modern Peer-to-Peer |
170 |
systems fall: the loosely structured approach and the tightly structured approach. By structure, we refer to |
systems fall: the loosely structured approach and the tightly structured approach. |
171 |
the topology of the overlay network, i.e., how the connections between participating peers are created |
By structure, we refer to the topology of the overlay network, i.e., how the connections between participating peers are created |
172 |
and maintained. By data lookup model, we mean the methods which are used for finding data from the overlay. |
and maintained. By data lookup model, we mean the methods which are used for finding data from the overlay. |
173 |
|
In the following sections, we will discuss in more detail the properties of these approaches. |
174 |
|
|
175 |
|
|
176 |
|
\section{Loosely structured} |
177 |
|
|
178 |
In the loosely structured approach the construction and the maintenance of the overlay is controlled |
In the loosely structured approach the construction and the maintenance of the overlay is controlled |
179 |
loosely. The placement of services and topology of the overlay is random. The data lookup model in loosely structured systems is |
loosely. The placement of services and topology of the overlay is random. The data lookup model in loosely structured systems is |
180 |
not very efficient, because of unstructured properties of the overlay. On the other hand, in the tightly structured |
not very efficient, because of unstructured properties of the overlay. |
|
approach the overlay is constructed determistically, which all participating peers have to follow. The topology of the |
|
|
overlay and the placement of services is controlled tightly therefore enabling more scalable and efficient data lookup model. |
|
181 |
|
|
182 |
In the following sections, we will discuss in more detail the properties of these approaches. |
\subsection{Sketch of a formal definition} |
183 |
|
|
184 |
|
In this subsection we formalize loosely structured overlay's main components. This |
185 |
|
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 |
188 |
|
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 |
190 |
|
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))$. |
192 |
|
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$, |
194 |
|
where $sp$ = $\delta(\gamma(\delta(s))) \wedge (p = \delta(s))$\} |
195 |
|
|
196 |
\section{Centralized} |
\subsection{Systems} |
197 |
|
|
198 |
Napster\footnote{We decided to include Napster in this section only because it has |
Napster\footnote{We decided to include Napster in this section only because it has |
199 |
historical value (see previous section).} \cite{napsterurl} was designed to allow |
historical value (see previous section).} \cite{napsterurl} was designed to allow |
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 well because of constantly updated central |
205 |
directory, and had a single point of failure. |
directory, and had a single point of failure. |
|
|
|
|
|
|
|
\section{Loosely structured} |
|
|
|
|
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 network. 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. |
223 |
In Gnutella, each participating peer maintains a local index of its own shared content. Also, |
In Gnutella, each participating peer maintains a local index of its own shared content. Also, |
224 |
each peer has some connections to other peers, i.e., the peer's \emph{neighbors}. Basic Gnutella |
each peer has some connections to other peers, i.e., the peer's \emph{neighbors}. Basic Gnutella |
225 |
data lookup works as follows: a peer broadcasts a query request to its neighbors, which in turn |
data lookup works as follows: a peer broadcasts a query request to its neighbors, which in turn |
226 |
forward the query to their neighbors. This leads to a situation where the number of messages |
forward the query to their neighbors. The number of messages |
227 |
in the network can grow with $O(n^{2})$ where $n$ is the number of participating peers in the |
in the network can grow with $O(n^{2})$ where $n$ is the number of participating peers in the |
228 |
Gnutella network. Figure \ref{fig:gnutella_query} illustrates why Gnutella's data lookup model has |
Gnutella network. Figure \ref{fig:gnutella_query} illustrates why Gnutella's data lookup model has |
229 |
exponential properties. To limit the amount of network traffic, Gnutella uses Time-To-Live-limited |
$O(n^{2})$ properties. |
230 |
|
|
231 |
|
To limit the amount of network traffic, Gnutella uses Time-To-Live-limited |
232 |
(TTL) flooding to distribute queries. Therefore, Gnutella's data lookup algorithm is a Breadth-First-Search (BFS) |
(TTL) flooding to distribute queries. Therefore, Gnutella's data lookup algorithm is a Breadth-First-Search (BFS) |
233 |
with depth limit $T$ (e.g., 7), where $T$ is the system-wide maximum TTL of a message in hops. Thus, |
with depth limit $T$ (e.g., 7), where $T$ is the system-wide maximum TTL of a message in hops. Thus, |
234 |
only peers that are TTL hops away from the query originator will forward the query or respond to the query. |
only peers that are TTL hops away from the query originator will forward the query or respond to the query. |
252 |
significant message processing overhead for each data lookup. Even worse, flooding may increase |
significant message processing overhead for each data lookup. Even worse, flooding may increase |
253 |
the load on participating peer to the point where it has to leave the network. |
the load on participating peer to the point where it has to leave the network. |
254 |
|
|
|
Lately, Gnutella's data lookup efficiency and scalability has been researched. |
|
255 |
Adamic et al. \cite{adamic99small, adamic02localsearch, adamic01powerlawsearch} |
Adamic et al. \cite{adamic99small, adamic02localsearch, adamic01powerlawsearch} |
256 |
have studied different data lookup methods in power-law networks and have found that by |
have studied different data lookup methods in power-law networks and have found that by |
257 |
instructing the peers that forward data lookups to select high degree peers, the performance of data lookup |
instructing the peers that forward data lookups to select high degree peers, the performance of data lookup |
258 |
increases significantly. As a result, some of the most recent loosely |
increases significantly. Figure \ref{fig:gnutella_powerlaw} presents an example topology of power-law network with three high |
259 |
structured Peer-to-Peer systems have adopted this method to improve Gnutella's data lookup model. Improvements |
degree peers. Some of the most recent loosely structured Peer-to-Peer systems have adopted this method to improve the data lookup model of loosely structured |
260 |
to the original Gnutella protocol \cite{gnutellaurl} include \cite{gnutella2url, shareazaurl} and improvements to the |
systems \cite{gnutella2url, fasttrackurl}. Both protocols use high degree peers to optimize the data lookup model of the |
261 |
FastTrack protocol \cite{fasttrackurl} include \cite{morpheusurl, kazaaurl}. Figures \ref{fig:gnutella_overlay_supernodes} |
system. Shareaza \cite{shareazaurl} uses the Gnutella2 protocol \cite{gnutella2url} in data lookups, Morpheus \cite{morpheusurl} |
262 |
and \ref{fig:gnutella_overlay_cluster} illustrates simplified variations of power-law overlay networks. |
and KaZaa \cite{kazaaurl} use the FastTrack protocol \cite{fasttrackurl}. |
263 |
Figure \ref{fig:gnutella_powerlaw} presents pure topology of power-law network. |
It is not clear whether the power-law method is scalable or not, |
|
|
|
|
It is not clear whether this algorithm is scalable or not, |
|
264 |
as the majority of the query requests are sent only to the high degree peers while making |
as the majority of the query requests are sent only to the high degree peers while making |
265 |
these peers to bear the load of the entire system. |
these peers to bear the load of the entire system. |
266 |
|
|
267 |
\begin{figure} |
%\begin{figure} |
268 |
\centering |
%\centering |
269 |
\includegraphics[width=8cm, height=6cm]{gnutella_overlay_supernodes.eps} |
%\includegraphics[width=8cm, height=6cm]{gnutella_overlay_supernodes.eps} |
270 |
\caption{Variation of power-law overlay topology with super peers.} |
%\caption{Variation of power-law overlay topology with super peers.} |
271 |
\label{fig:gnutella_overlay_supernodes} |
%\label{fig:gnutella_overlay_supernodes} |
272 |
\end{figure} |
%\end{figure} |
273 |
|
|
274 |
\begin{figure} |
%\begin{figure} |
275 |
\centering |
%\centering |
276 |
\includegraphics[width=10cm, height=6cm]{gnutella_overlay_clusters.eps} |
%\includegraphics[width=10cm, height=6cm]{gnutella_overlay_clusters.eps} |
277 |
\caption{Variation of power-law overlay topology with 2-redundant super peer clusters.} |
%\caption{Variation of power-law overlay topology with 2-redundant super peer clusters.} |
278 |
\label{fig:gnutella_overlay_cluster} |
%\label{fig:gnutella_overlay_cluster} |
279 |
\end{figure} |
%\end{figure} |
280 |
|
|
281 |
\begin{figure} |
\begin{figure} |
282 |
\centering |
\centering |
283 |
\includegraphics[width=10cm, height=8cm]{gnutella_powerlaw.eps} |
\includegraphics[width=10cm, height=8cm]{gnutella_powerlaw.eps} |
284 |
\caption{Pure power-law network overlay topology with three super peers.} |
\caption{Pure power-law network overlay topology with three high degree peers.} |
285 |
\label{fig:gnutella_powerlaw} |
\label{fig:gnutella_powerlaw} |
286 |
\end{figure} |
\end{figure} |
287 |
|
|
288 |
Previously presented improvements are only partial solutions. More advanced techniques |
Above presented improvements are only partial solutions. More advanced techniques |
289 |
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. Yet, however, |
290 |
|
techniques presented in chapter 3 are not adopted in any loosely structured system. |
291 |
|
|
292 |
\subsection{Sketch of a formal definition} |
\section{Tightly structured} |
293 |
|
|
294 |
In this subsection we formalize loosely structured overlay's main components. This |
Partly due to scalability problems of loosely structured systems, several tightly |
295 |
model is based on original Gnutella overlay network with scale-free improvements. |
structured overlays have been proposed. In the tightly structured |
296 |
|
approach the overlay is constructed determistically, which all participating peers have to follow. The topology of the |
297 |
|
overlay and the placement of services is controlled tightly therefore enabling more scalable and efficient data lookup model. |
298 |
|
|
299 |
Let $S$ be the aggregate of all services $s$ in system. Let $P$ be the aggregate of |
\subsection{Sketch of a formal definition} |
|
all peers $p$ in system. Then, $\forall s \in S$, there is a provider of the service, |
|
|
expressed as $p = \delta(s)$. Every $p$ has neighbor(s), named as $p_n$, which |
|
|
is $P$ = \{$p \in P: \exists neighbor$, which is randomly chosen from $P$\}. |
|
|
Summary index maintains indices of other peers, $si = \gamma(\delta(s))$. |
|
|
Then, $\forall$ regular peer $p$, there is a super peer, $sp$, and it has a index of |
|
|
regular peer's content $P$ = \{$p \in P: \exists sp$, |
|
|
where $sp$ = $\delta(\gamma(\delta(s))) \wedge (p = \delta(s))$\} |
|
300 |
|
|
301 |
\section{Tightly structured} |
In this subsection, we formalize the main features of tightly structured overlay, i.e., |
302 |
|
identifiers, identifier space and the mapping function. |
303 |
|
|
304 |
Partly due to scalability problems of loosely structured systems, several tightly |
Let $S$ be the aggregate of all services $s$ in the system. Let $P$ be the aggregate of |
305 |
structured overlays have been proposed. |
all peers $p$ in system. Let $I$ be the aggregate of all identifiers $i$ in system. |
306 |
The list includes CAN \cite{ratnasamy01can}, Chord \cite{stoica01chord}, |
Let $IS$ be the aggregate of all identifier points $ip$ in system. Then, $\forall s \in S$, |
307 |
Kademlia \cite{maymounkov02kademlia}, Kelips \cite{gupta03kelips}, |
there is a provider of the service, expressed as $p = \delta(s)$. Service's identifier |
308 |
Koorde \cite{kaashoek03koorde}, Overlapping Distance Halving Distributed Hashtable |
is defined as $i = \iota(s)$. Coordinate point is defined as $ip = \zeta(\iota(s))$. |
309 |
(ODHDHT) \cite{naor03simpledht}, Pastry \cite{rowston01pastry}, PeerNet \cite{eriksson03peernet}, |
Metric space is defined as a pair $(IS,d)$, where $d$ is the distance between two coordinate |
310 |
Skip Graphs \cite{AspnesS2003}, SkipNet \cite{harvey03skipnet2}, |
points $ip_i$, $ip_j$ in $IS$ space. Mapping function is defined as $\zeta: I \longmapsto IS$, |
311 |
Symphony \cite{gurmeet03symphony}, SWAN \cite{bonsma02swan}, Tapestry |
which maps data items, expressed by an identifier to coordinate point $ip$ in $(IS,d)$. Peer's $p$ |
312 |
\cite{zhao01tapestry}, Viceroy \cite{malkhi02viceroy} and others \cite{freedman02trie}. |
resources are mapped onto a set $IS$ = \{$ip \in IS: \exists s \in S$, $ip = \zeta(\iota(s)) \wedge (\delta(s) = p)$\}. |
313 |
|
Every $p$ has neighbor(s), named as $p_n$, $P$ = \{$p \in P: \exists p_n$, |
314 |
|
where $\theta(p,p_n) = ''close''$, where $''close''$ is small difference $d$ in $(IS,d)$\}. |
315 |
|
|
316 |
|
\subsection{Systems} |
317 |
|
|
318 |
The biggest difference compared to the loosely structured approach is that with tightly structured systems, |
The biggest difference compared to the loosely structured approach is that with tightly structured systems, |
319 |
it is now feasible to perform \emph{global} data lookups in the overlay. |
it is now feasible to perform \emph{global} data lookups in the overlay. By global lookup, we mean |
320 |
|
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. Furthermore, globally unique identifiers |
466 |
$O(\log{n})$ data lookup efficiency. |
$O(\log{n})$ data lookup efficiency. |
467 |
|
|
468 |
|
|
|
\subsection{Sketch of a formal definition} |
|
|
|
|
|
In this subsection, we formalize the main features of tightly structured overlay, i.e., |
|
|
identifiers, identifier space and the mapping function. |
|
|
|
|
|
Let $S$ be the aggregate of all services $s$ in the system. Let $P$ be the aggregate of |
|
|
all peers $p$ in system. Let $I$ be the aggregate of all identifiers $i$ in system. |
|
|
Let $IS$ be the aggregate of all identifier points $ip$ in system. Then, $\forall s \in S$, |
|
|
there is a provider of the service, expressed as $p = \delta(s)$. Service's identifier |
|
|
is defined as $i = \iota(s)$. Coordinate point is defined as $ip = \zeta(\iota(s))$. |
|
|
Metric space is defined as a pair $(IS,d)$, where $d$ is the distance between two coordinate |
|
|
points $ip_i$, $ip_j$ in $IS$ space. Mapping function is defined as $\zeta: I \longmapsto IS$, |
|
|
which maps data items, expressed by an identifier to coordinate point $ip$ in $(IS,d)$. Peer's $p$ |
|
|
resources are mapped onto a set $IS$ = \{$ip \in IS: \exists s \in S$, $ip = \zeta(\iota(s)) \wedge (\delta(s) = p)$\}. |
|
|
Every $p$ has neighbor(s), named as $p_n$, $P$ = \{$p \in P: \exists p_n$, |
|
|
where $\theta(p,p_n) = ''close''$, where $''close''$ is small difference $d$ in $(IS,d)$\}. |
|
|
|
|
|
|
|
469 |
\section{Summary} |
\section{Summary} |
470 |
|
|
471 |
In this section we compare the loosely structured approach and the tightly structured approach. |
In this section we compare the loosely structured approach and the tightly structured approach. |