192 |
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. |
193 |
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 |
194 |
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} |
195 |
illustrates the overlay network of Gnutella network. The Gnutella network can be considered as a variation of \emph{scale-free |
illustrates the overlay network of Gnutella network. The Gnutella network can be considered as a variation of scale-free |
196 |
graph}. In scale-free graphs (also known as power-law graphs) only a few peers have high number of neighbor |
graph \cite{albert-02-statistical}. In scale-free graphs only a few peers have high |
197 |
links and the majority of peers have low number of neighbor links. |
number of neighbor links and the majority of peers have low number of neighbor links. |
198 |
|
|
199 |
\begin{figure} |
\begin{figure} |
200 |
\centering |
\centering |
205 |
|
|
206 |
|
|
207 |
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, |
208 |
each peer has a few connections to other peers, i.e., peer's \emph{neighbors}. Basic Gnutella |
each peer has some connections to other peers, i.e., the peer's \emph{neighbors}. Basic Gnutella |
209 |
data lookup works as follows: 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 |
210 |
forward the query to their neighbors. This leads to a situation where the number of messages |
forward the query to their neighbors. This leads to a situation where the number of messages |
211 |
in the network can grow with $O(n^{2})$, where $n$ is the number of participating peers in |
in the network can grow with $O(n^{2})$ where $n$ is the number of participating peers in the |
212 |
Gnutella network. To limit the amount of network traffic, Gnutella uses Time-To-Live-limited |
Gnutella network. Figure \ref{fig:gnutella_query} illustrates why Gnutella's data lookup model has |
213 |
(TTL) flooding to distribute queries. Therefore, Gnutella uses a Breadth-First-Search (BFS) algorithm |
exponential properties. To limit the amount of network traffic, Gnutella uses Time-To-Live-limited |
214 |
|
(TTL) flooding to distribute queries. Therefore, Gnutella's data lookup algorithm is a Breadth-First-Search (BFS) |
215 |
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, |
216 |
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. |
217 |
In Gnutella network, search results are fast, because BFS sends queries to |
In the Gnutella network, search results are fast, because BFS sends queries to |
218 |
every possible neighbor. Clearly, this method wastes resources and doesn't scale well. |
every possible neighbor. Clearly, this method wastes resources and doesn't scale well. |
219 |
Figure \ref{fig:gnutella_query} shows the data lookup process of the Gnutella network. |
|
220 |
|
|
221 |
\begin{figure} |
\begin{figure} |
222 |
\centering |
\centering |
226 |
\end{figure} |
\end{figure} |
227 |
|
|
228 |
According to \cite{lv02searchreplication}, Gnutella's way to perform data lookups, \emph{flooding}, has the |
According to \cite{lv02searchreplication}, Gnutella's way to perform data lookups, \emph{flooding}, has the |
229 |
following limitations. First, choosing the appropriate TTL in practice is not easy. If the |
following limitations. First, choosing the appropriate TTL is not easy. If the |
230 |
TTL is too high, query originator may unnecessarily strain the network. If the TTL is too |
TTL is too high, the query originator may unnecessarily strain the network. If the TTL is too |
231 |
low, the query originator might not find the desired data even if it is available somewhere |
low, the query originator might not find the desired data even if it is available somewhere |
232 |
in the network. Second, there are many duplicate messages generated by flooding, especially |
in the network. Second, there are many duplicate messages generated by flooding, especially |
233 |
in high connectivity graphs. It is obvious that with these limitations, flooding creates |
in high connectivity graphs. It is obvious that with these limitations, flooding creates |
234 |
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 |
235 |
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. |
236 |
|
|
237 |
Lately, Gnutella's data lookup efficiency and scalability has been deeply researched. |
Lately, Gnutella's data lookup efficiency and scalability has been researched. |
238 |
Adamic et al. \cite{adamic99small, adamic02localsearch, adamic01powerlawsearch} |
Adamic et al. \cite{adamic99small, adamic02localsearch, adamic01powerlawsearch} |
239 |
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 |
240 |
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 |
241 |
increases significantly. As a result, some of the most recent loosely |
increases significantly. As a result, some of the most recent loosely |
242 |
structured Peer-to-Peer systems have adopted this method with some modifications |
structured Peer-to-Peer systems have adopted this method to improve Gnutella's data lookup model. Improvements |
243 |
\cite{gnutella2url, shareazaurl, fasttrackurl, morpheusurl, kazaaurl, waterhouse02searchp2p, botros01jxtasearch, |
to the original Gnutella protocol \cite{gnutellaurl} include \cite{gnutella2url, shareazaurl} and improvements to the |
244 |
ganesan02yappers}. |
FastTrack protocol \cite{fasttrackurl} include \cite{morpheusurl, kazaaurl}. Figures \ref{fig:gnutella_overlay_supernodes} |
245 |
Figures \ref{fig:gnutella_overlay_supernodes} and \ref{fig:gnutella_overlay_cluster} |
and \ref{fig:gnutella_overlay_cluster} illustrates simplified variations of power-law overlay networks. |
246 |
illustrates simplified variations of power-law overlay networks. Figure \ref{fig:gnutella_powerlaw} |
Figure \ref{fig:gnutella_powerlaw} presents pure topology of power-law network. |
|
presents pure topology of power-law network. |
|
247 |
|
|
248 |
It is not clear whether this algorithm is scalable or not, |
It is not clear whether this algorithm is scalable or not, |
249 |
as the majority of the query requests are sent only to the high degree peers, making |
as the majority of the query requests are sent only to the high degree peers while making |
250 |
them stress the load of entire system. |
these peers to bear the load of the entire system. |
251 |
|
|
252 |
\begin{figure} |
\begin{figure} |
253 |
\centering |
\centering |
1396 |
\parbox{90pt}{Efficient and scalable data discovery \cite{lv02searchreplication, osokine02distnetworks, yang02improvingsearch, lv02gnutellascalable, |
\parbox{90pt}{Efficient and scalable data discovery \cite{lv02searchreplication, osokine02distnetworks, yang02improvingsearch, lv02gnutellascalable, |
1397 |
ganesan02yappers, adamic02localsearch, adamic01powerlawsearch, ripeanu02mappinggnutella, milgram67smallworld, adamic99small, |
ganesan02yappers, adamic02localsearch, adamic01powerlawsearch, ripeanu02mappinggnutella, milgram67smallworld, adamic99small, |
1398 |
ramanathan02goodpeers, kleinberg99small, nips02-Kleinberg, zhang02using, watts00dynamics, karger02findingnearest, |
ramanathan02goodpeers, kleinberg99small, nips02-Kleinberg, zhang02using, watts00dynamics, karger02findingnearest, |
1399 |
brinkmann02compactplacement, rhea02probabilistic, castro02networkproximity, ng02predicting, pias03lighthouse}} & |
brinkmann02compactplacement, rhea02probabilistic, castro02networkproximity, ng02predicting, pias03lighthouse, waterhouse02searchp2p, botros01jxtasearch, |
1400 |
|
ganesan02yappers}} & |
1401 |
\parbox{110pt}{Find resources efficiently, if resource exists (loosely structured)} & |
\parbox{110pt}{Find resources efficiently, if resource exists (loosely structured)} & |
1402 |
\parbox{110pt}{Super peers, peer clusters, caching techniques} & |
\parbox{110pt}{Super peers, peer clusters, caching techniques} & |
1403 |
\parbox{110pt}{More efficient, less network traffic, not comparable to the efficiency of tightly structured systems} |
\parbox{110pt}{More efficient, less network traffic, not comparable to the efficiency of tightly structured systems} |