27 |
|
|
28 |
\tyyppi{pro gradu-tutkielma} |
\tyyppi{pro gradu-tutkielma} |
29 |
|
|
30 |
\keywords{Peer-to-Peer, P2P, networking, distributen computing} |
\keywords{Peer-to-Peer, Peer-to-Peer, networking, distributen computing} |
31 |
|
|
32 |
\avainsanat{Vertaisverkot, P2P, tietoverkot, hajautetut järjestelmät} |
\avainsanat{Vertaisverkot, Peer-to-Peer, tietoverkot, hajautetut järjestelmät} |
33 |
|
|
34 |
\contactinformation{\\ |
\contactinformation{\\ |
35 |
Hermanni Hyytiälä\\ |
Hermanni Hyytiälä\\ |
55 |
|
|
56 |
\chapter{Introduction} |
\chapter{Introduction} |
57 |
|
|
58 |
Peer-to-Peer (P2P) systems can be characterized as distributed systems in which all |
Peer-to-Peer (Peer-to-Peer) systems can be characterized as distributed systems in which all |
59 |
communication is symmetric and all participants have identical capabilities and responsabilities. |
communication is symmetric and all participants have identical capabilities and responsabilities. |
60 |
Each participant may contribute data or computing resources (such as unused storage) to the overall |
Each participant may contribute data or computing resources (such as unused storage) to the overall |
61 |
system, and the welfare of the community can scale with ne number of participants. Therefore each |
system, and the welfare of the community can scale with ne number of participants. Therefore each |
62 |
participant rely on one another services and resources, rather than solely relying on dedicated |
participant rely on one another services and resources, rather than solely relying on dedicated |
63 |
centralized infracstructure. |
centralized infracstructure. |
64 |
|
|
65 |
P2P systems have recently received significant attention in both academia and industry for a number |
Peer-to-Peer systems have recently received significant attention in both academia and industry for a number |
66 |
of reasons. First, the lack of decentralization means that participants can form a P2P system without any |
of reasons. First, the lack of decentralization means that participants can form a Peer-to-Peer system without any |
67 |
investment to high-priced hardware to coordinate it. Moreover, P2P systems provides aggregation of enormous |
investment to high-priced hardware to coordinate it. Moreover, Peer-to-Peer systems provides aggregation of enormous |
68 |
resources and way to achieve interoperability. Finally, the distributed nature of P2P improves scalability |
resources and way to achieve interoperability. Finally, the distributed nature of Peer-to-Peer improves scalability |
69 |
and reliability againts certain kinds of faults, e.g. single point of failure. |
and reliability againts certain kinds of faults, e.g. single point of failure. |
70 |
|
|
71 |
\chapter{Terminology} |
\cite{p2pworkinggroup} |
72 |
|
\cite{graham02lecture} |
73 |
|
\cite{winer00whatisp2p} |
74 |
|
|
75 |
|
\chapter{Peer-to-Peer approaches} |
76 |
|
|
77 |
|
\section{General} |
78 |
|
|
79 |
|
\cite{levy90distributedfilesystems} |
80 |
|
\cite{339345} |
81 |
|
\cite{albert-02-statistical} |
82 |
|
\cite{albert-00-tolerance} |
83 |
|
\cite{balakrishanarticle03lookupp2p} |
84 |
|
|
|
\chapter{Overview of Peer-to-Peer} |
|
85 |
|
|
86 |
This section discusses briefly general aspects of P2P systems. A more detailed general discussion can be found |
\begin{figure} |
87 |
from \cite{milojicic02peertopeer, oram01harnessingpower}. |
\centering |
88 |
|
\includegraphics[width=10cm, height=8cm]{application_level_overlay.eps} |
89 |
|
\caption{Peer-to-Peer Application Level Overlay} |
90 |
|
\label{fig:application_level} |
91 |
|
\end{figure} |
92 |
|
|
93 |
|
|
94 |
|
\section{Centralized} |
95 |
|
|
96 |
|
\cite{napsterurl} |
97 |
|
|
98 |
|
\section{Unstructured} |
99 |
|
|
100 |
|
\begin{figure} |
101 |
|
\centering |
102 |
|
\includegraphics[width=6cm, height=6cm]{gnutella_overlay.eps} |
103 |
|
\caption{Gnutella overlay network} |
104 |
|
\label{fig:gnutella_overlay} |
105 |
|
\end{figure} |
106 |
|
|
107 |
|
\subsection{Protocols} |
108 |
|
|
109 |
|
\cite{clarke00freenet} |
110 |
|
\cite{zhang02using} |
111 |
|
\cite{milgram67smallworld} |
112 |
|
\cite{adamic99small} |
113 |
|
\cite{ramanathan02goodpeers} |
114 |
|
\cite{kleinberg99small} |
115 |
|
\cite{watts00dynamics} |
116 |
|
\cite{nips02-Kleinberg} |
117 |
|
\cite{ganesan02yappers} |
118 |
|
\cite{gnutellaurl} |
119 |
|
\cite{gnutella2url} |
120 |
|
\cite{shareazaurl} |
121 |
|
\cite{fasttrackurl} |
122 |
|
\cite{morpheusurl} |
123 |
|
\cite{kazaaurl} |
124 |
|
\cite{jxtaurl} |
125 |
|
\cite{jxtaoverview} |
126 |
|
\cite{botros01jxtasearch} |
127 |
|
\cite{kato02gisp} |
128 |
|
\cite{alpineurl} |
129 |
|
\cite{joseph02neurogrid} |
130 |
|
|
131 |
|
|
132 |
|
\subsection{Super peers} |
133 |
|
|
134 |
|
\begin{figure} |
135 |
|
\centering |
136 |
|
\includegraphics[width=8cm, height=6cm]{gnutella_overlay_supernodes.eps} |
137 |
|
\caption{Gnutella overlay network with super nodes} |
138 |
|
\label{fig:gnutella_overlay_supernodes} |
139 |
|
\end{figure} |
140 |
|
|
141 |
|
\subsection{Super peer clusters} |
142 |
|
|
143 |
|
\begin{figure} |
144 |
|
\centering |
145 |
|
\includegraphics[width=10cm, height=6cm]{gnutella_overlay_clusters.eps} |
146 |
|
\caption{Gnutella overlay network with 2-redundant super node clusters} |
147 |
|
\label{fig:gnutella_overlay_cluster} |
148 |
|
\end{figure} |
149 |
|
|
150 |
|
|
151 |
|
\begin{figure} |
152 |
|
\centering |
153 |
|
\includegraphics[width=8cm, height=6cm]{gnutella_query.eps} |
154 |
|
\caption{Basic Gnutella query} |
155 |
|
\label{fig:gnutella_query} |
156 |
|
\end{figure} |
157 |
|
|
158 |
|
|
159 |
|
|
160 |
|
|
161 |
|
\section{Structured} |
162 |
|
|
163 |
|
\cite{aspnes02faultrouting} |
164 |
|
\cite{ratnasamy02ght} |
165 |
|
\cite{236713} |
166 |
|
\cite{258660} |
167 |
|
|
168 |
|
\cite{fips-sha-1} |
169 |
|
|
170 |
|
\subsection{Protocols} |
171 |
|
|
172 |
|
\cite{zhao01tapestry} |
173 |
|
|
174 |
|
\cite{rowston01pastry} |
175 |
|
|
176 |
|
\cite{stoica01chord} |
177 |
|
|
178 |
|
\cite{ratnasamy01can} |
179 |
|
|
180 |
|
\cite{maymounkov02kademlia} |
181 |
|
|
182 |
|
\cite{freedman02trie} |
183 |
|
|
184 |
|
\cite{plaxton97accessingnearby} |
185 |
|
|
186 |
|
\cite{malkhi02viceroy} |
187 |
|
|
188 |
|
\cite{bonsma02swan} |
189 |
|
|
190 |
|
\cite{AspnesS2003} |
191 |
|
\cite{78977} |
192 |
|
|
193 |
|
\cite{gurmeet03symphony} |
194 |
|
|
195 |
|
\cite{eriksson03peernet} |
196 |
|
|
197 |
|
\cite{harvey03skipnet2} |
198 |
|
|
199 |
|
|
200 |
|
\cite{garciamolina03sil} |
201 |
|
|
202 |
|
\cite{rowston03controlloingreliability} |
203 |
|
|
204 |
|
\cite{Bhattacharjee03resultcache} |
205 |
|
|
206 |
|
\cite{byers03dhtbalancing} |
207 |
|
|
208 |
|
\cite{pias03lighthouse} |
209 |
|
|
210 |
|
\cite{naor03simpledht} |
211 |
|
|
212 |
|
\cite{gupta03kelips} |
213 |
|
|
214 |
|
\cite{kaashoek03koorde} |
215 |
|
\cite{debruijn46graph} |
216 |
|
|
217 |
|
|
218 |
|
|
219 |
|
|
220 |
|
\subsection{Distributed Hash Table (DHT)} |
221 |
|
|
222 |
|
\cite{Gribble:2000:SDD} |
223 |
|
|
224 |
|
\cite{dabek01widearea} |
225 |
|
|
226 |
|
\cite{iyer02squirrel} |
227 |
|
|
228 |
|
\cite{harrisoncircle} |
229 |
|
|
230 |
|
\cite{rowstron01storage} |
231 |
|
|
232 |
|
\subsection{Decentralized Object Location and Routing Networks (DOLR)} |
233 |
|
|
234 |
|
\cite{kubiatowicz00oceanstore} |
235 |
|
|
236 |
|
\begin{figure} |
237 |
|
\centering |
238 |
|
\includegraphics[width=14cm, height=8cm]{structured_overlay.eps} |
239 |
|
\caption{Generation of structured overlay network} |
240 |
|
\label{fig:structured_hashing} |
241 |
|
\end{figure} |
242 |
|
|
243 |
|
|
244 |
|
|
245 |
|
\begin{figure} |
246 |
|
\centering |
247 |
|
\includegraphics[width=8cm, height=6cm]{structured_query.eps} |
248 |
|
\caption{Simplified structured system's query} |
249 |
|
\label{fig:structured_query} |
250 |
|
\end{figure} |
251 |
|
|
252 |
|
\section{Summary} |
253 |
|
|
254 |
|
|
255 |
|
|
256 |
|
|
257 |
|
|
258 |
|
|
259 |
|
|
260 |
|
|
261 |
|
|
262 |
|
|
263 |
|
|
264 |
|
|
265 |
|
\subsection{Protocols} |
266 |
|
|
267 |
|
|
268 |
|
\scriptsize |
269 |
|
\begin{longtable}{|l|c|c|c|c|l|} |
270 |
|
\caption[Different Peer-to-Peer lookup protocols]{Different Peer-to-Peer lookup protocols} |
271 |
|
\label{table_Peer-to-Peer_protocols} \\ |
272 |
|
|
273 |
|
\hline |
274 |
|
\multicolumn{1}{|c|}{\textbf{Protocol}} & |
275 |
|
\multicolumn{1}{c|}{\textbf{Insert/Delete}} & |
276 |
|
\multicolumn{1}{c|}{\textbf{Space}} & |
277 |
|
\multicolumn{1}{c|}{\textbf{Lookup}} & |
278 |
|
\multicolumn{1}{c|}{\textbf{\# of network connections}} & |
279 |
|
\multicolumn{1}{c|}{\textbf{Notes}} |
280 |
|
\\ \hline |
281 |
|
\endfirsthead |
282 |
|
|
283 |
|
\multicolumn{6}{c}% |
284 |
|
{{\tablename\ \thetable{} -- continued from previous page}} \\ |
285 |
|
\hline |
286 |
|
\multicolumn{1}{|c|}{\textbf{Protocol}} & |
287 |
|
\multicolumn{1}{c|}{\textbf{Insert/Delete}} & |
288 |
|
\multicolumn{1}{c|}{\textbf{Space}} & |
289 |
|
\multicolumn{1}{c|}{\textbf{Lookup}} & |
290 |
|
\multicolumn{1}{c|}{\textbf{\# of network connections}} & |
291 |
|
\multicolumn{1}{c|}{\textbf{Notes}} |
292 |
|
\\ \hline |
293 |
|
\endhead |
294 |
|
|
295 |
|
\endfoot |
296 |
|
|
297 |
|
\parbox{37pt}{CAN} & |
298 |
|
\parbox{37pt}{$O$($d$)} & |
299 |
|
\parbox{37pt}{$O$($d$)} & |
300 |
|
\parbox{37pt}{$O(dn^{\frac{1}{d}})$} & |
301 |
|
\parbox{85pt}{2$d$} & |
302 |
|
\parbox{85pt}{System's performance may decrease if nodes are not homogeneous and nodes join and leave the system in a dynamic manner, where $d$ is the dimension of virtual key space} |
303 |
|
\\ \hline |
304 |
|
|
305 |
|
\parbox{37pt}{Chord} & |
306 |
|
\parbox{37pt}{$O(\log^2{n})$} & |
307 |
|
\parbox{37pt}{$O(\log{n}$} & |
308 |
|
\parbox{37pt}{$O(\log{n})$} & |
309 |
|
\parbox{85pt}{2$(\log{n})$} & |
310 |
|
\parbox{85pt}{System's performance may decrease if nodes are not homogeneous and nodes join and leave the system in a dynamic manner} |
311 |
|
\\ \hline |
312 |
|
|
313 |
|
|
314 |
|
\parbox{37pt}{Freenet} & |
315 |
|
\parbox{37pt}{$O(1)$} & |
316 |
|
\parbox{37pt}{$O(1)$} & |
317 |
|
\parbox{37pt}{$O(n)$} & |
318 |
|
\parbox{85pt}{Typical configuration e.g., {4--150}} & |
319 |
|
\parbox{85pt}{Average lookup performance is $O(\log{n})$ with tens of thousands concurrent users, beyond that, the performace is $O(n)$} |
320 |
|
\\ \hline |
321 |
|
|
322 |
|
|
323 |
|
\parbox{37pt}{Gnutella} & |
324 |
|
\parbox{37pt}{$O(1)$} & |
325 |
|
\parbox{37pt}{$O(1)$} & |
326 |
|
\parbox{37pt}{$O(n)$} & |
327 |
|
\parbox{85pt}{Typical configuration is 5 connections (2*5=10 total), however, depends on implementation} & |
328 |
|
\parbox{85pt}{Number of messages can grow as fast as $O(n^{2})$} |
329 |
|
\\ \hline |
330 |
|
|
331 |
|
|
332 |
|
\parbox{37pt}{Kademlia} & |
333 |
|
\parbox{37pt}{$O(\log{n})$} & |
334 |
|
\parbox{37pt}{$O(\log{n})$} & |
335 |
|
\parbox{37pt}{$O(\log{n})$} & |
336 |
|
\parbox{85pt}{$2(\log{n})$} & |
337 |
|
\parbox{85pt}{There is no action required when nodes leaves the system} |
338 |
|
\\ \hline |
339 |
|
|
340 |
|
|
341 |
|
\parbox{37pt}{Kelips} & |
342 |
|
\parbox{37pt}{$O(2(\sqrt{n}*(log^2{n})) + (\sqrt{n} + (log^3{n})))$} & |
343 |
|
\parbox{37pt}{$O$($\sqrt{n}$)} & |
344 |
|
\parbox{37pt}{$O(1)$} & |
345 |
|
\parbox{85pt}{$\frac{n}{\sqrt{n}} + c*(\sqrt{n}-1) + \frac{Totalnumber of files}{\sqrt{n}}$, where n is the number of nodes and c the number of contacts/foreign affinity group} & |
346 |
|
\parbox{85pt}{Insert/delete overhead is constant and performed background, System's performance may decrease if nodes are not homogeneous and nodes join and leave the system in a dynamic manner} |
347 |
|
\\ \hline |
348 |
|
|
349 |
\section{What is Peer-to-Peer ?} |
\parbox{37pt}{Koorde} & |
350 |
|
\parbox{37pt}{$O(\log^2{n})$} & |
351 |
\subsection{Definition} |
\parbox{37pt}{$O(1)$ or $O(\log{n})$} & |
352 |
Altough the exact definition of "peer-to-peer" (P2P) is debatable, these systems typically lack dedicated, centralized |
\parbox{37pt}{$O(\log{n})$ or $O(\frac{\log{n}}{\log{}\log{n}})$} & |
353 |
infrastructure, resources and services depends on the voluntary participation of peers. Because of that, the |
\parbox{85pt}{$2(\log{n})$} & |
354 |
challenge of such systems is to determine a archictecure for deploying participants in a such way so that they |
\parbox{85pt}{Based on Chord protocol, uses de Bruijn graphs for better efficiency/fault-tolerance} |
355 |
can efficiently cooperate to provide services and resources to the entire system. The resources comprise of |
\\ \hline |
356 |
computing power, data (content and storage), network bandwidth, and presence (human resources). Typical P2P |
|
357 |
systems reside on the edge of the Internet or in ad-hoc networks. As cited in \cite{milojicic02peertopeer}, |
\parbox{37pt}{ODHDHT} & |
358 |
"P2P enables valuable externalities, by aggregating resources through low-cost interoperability, the whole |
\parbox{37pt}{$O(\log{n})$} & |
359 |
is made greater than the sum of its parts". |
\parbox{37pt}{$O(\log{n})$} & |
360 |
|
\parbox{37pt}{$O(\log{n})$} & |
361 |
Many defitions of P2P have been proposed in P2P community. The Intel P2P Working Group \cite{p2pworkinggroup} |
\parbox{85pt}{$2(\log{n})$} & |
362 |
defines P2P as "the sharing of computer resources and services by direct exchange between systems". Ross Lee |
\parbox{85pt}{There are two lookup algorithms. The other is $O(\log{n})$, which is robus under random deletion. The second is $O(\log^2{n})$, which is also robust under spam generating model} |
363 |
Graham \cite{graham02lecture} defines P2P through three requirements: 1) System has an operational computer |
\\ \hline |
|
of server quality; 2) System has an addressing system independent of DNS; 3) System is able |
|
|
to cope with variable connectivity. O'Reilly's Clay Shirky proposes that "P2P is a class of applications |
|
|
that takes advantage of resources - storage, cycles, content, human presence - available at the edges |
|
|
of the Internet. Because accessing the decentralized resources means operating in a environment of unstable |
|
|
connectivity and unpredictable IP addresses, P2P nodes must operate outside the DNS system and have significant |
|
|
or total autonomy from central servers". Finally Dave Winer \cite{winer00whatisp2p} cites P2P as "A network |
|
|
app that doesn't run in a web browser...the user's machine is a client and a server...networks with other |
|
|
users, creating a community". |
|
364 |
|
|
|
Sharing is an essential part of P2P community. Every participant gives to and obtains resources from the community. |
|
|
For example, in Gnutella \cite {gnutellaurl} case, sharing is about offering data resources to the rest of the community |
|
|
and getting other data in return. On the another hand, P2P is way to aggregate tremendous amounts of computer power, |
|
|
storage, and connectivity from the different kind of computers around the world. SETI@Home \cite{setiurl} is an |
|
|
obvious an example of this approach. Based on definitions of P2P above, each participant in P2P system can be referred |
|
|
as equal as others in the community. Therefore, P2P system is one in which autonomous participant depend on other |
|
|
autonomous participants. Autonomy of participants, however, means that they cannot trust each other and rely |
|
|
completely on the resources which other peers provides. Issues related to scalability and profusion become |
|
|
more important than in centralized or traditional distributed systems. |
|
|
|
|
|
At the end, of course, P2P systems are an alternative to the centralized and client-server types of computing, |
|
|
where there is typically a single server (or small cluster) and many clients. See figure 1 for high-level difference |
|
|
of P2P versus centralized, client-server approach. |
|
|
|
|
|
[Figure 1. Insert picture] |
|
|
|
|
|
However, more detailed comparison of P2P systems and client-server approach is significantly more complex |
|
|
because: "There is no clear border between a client-server and a P2P model. Both models can be |
|
|
built on a spectrum of level of characteristics, functionality, organizations, components, protocols etc. Furthermore, |
|
|
one mode can be built on top of the other or parts of the components can be realized in one or the other model. Finally, |
|
|
both models can execute on different types of platforms and both can server as an underlying base for traditional |
|
|
and new applications. Therefore, it should not be a surprise that there is so much confusion about what P2P is |
|
|
and what it is not. It is extremely interwined with existing technologies" [Morgan 2002 REFERENCE!!!]. |
|
|
|
|
|
|
|
|
\subsection{History} |
|
|
|
|
|
The Internet has been originally established in the late 1960s. The objective of the ARPANET-project was to |
|
|
share computers' resources around the United States. The most challenging purpose of ARPANET was to |
|
|
integrate different kinds of existing network technologies with one common network architecture. The |
|
|
ARPANET connected the first few hosts together not in client/server relationship, but rather as |
|
|
equal networking peers. This could be seen as starting point both of P2P systems and |
|
|
Internet \cite{oram01harnessingpower}. |
|
|
|
|
|
While most early distributed applications can be considered P2P, file transfer protocol (FTP), Usenet and Telnet |
|
|
systems were probably the most extensively used. A Telnet client logged into a server, and |
|
|
an FTP client downloaded and sent data to a file server. In the case of Usenet, peer servers connected |
|
|
to other peers to deliver messages into the user's mail box or into a spool box containing messages from |
|
|
the newsgroups. Altough single application could be seen as was client/server relationship, the usage model as a |
|
|
whole were symmetric. Every computer on the ARPANET could create connections to any other computer and use |
|
|
each other's resources. The symmetry is what made the ARPANET so novel. As a implication, early ARPANET |
|
|
made possible to create more complex systems as DNS \cite{rfc1101}. |
|
|
|
|
|
In subsequent years, the Internet has become more restricted to client/server based applications. In |
|
|
recent years, however, P2P systems have emerged a significant social and technical phenomenon. It could |
|
|
be possible the Internet could revert to its initial symmetrical form. At the end, FTP can be considered as |
|
|
a predecessor to today's file-sharing P2P systems. The Archie, global indexing system, was developed to |
|
|
provide a central search infrastructure over existing FTP servers. Napster \cite{napsterurl} is a good |
|
|
example of this kind of approach in modern P2P file-sharing systems. |
|
|
|
|
|
\subsection{Characteristics of Peer-to-Peer} |
|
|
|
|
|
Decentralization |
|
|
In traditional client-server relationship, resources is preserved in centralized servers and distributed |
|
|
through network to client computers. P2P, however, takes a different approach; there is no centralized |
|
|
server or authority for distributing resources in the P2P network. Perhaps one of the most powerful ideas |
|
|
of decentralization is the stress on the participant's ownership and control of resources. As a implication |
|
|
in a fully decentralized system, every peer is an equal participant of the community. |
|
|
|
|
|
Scalability and Adaption |
|
|
Natural advantage of decentralization is improved scalability of the system. In P2P, scalability is limited |
|
|
by factors such as centralized manageability that needs to be performed and the amount of states need to be |
|
|
maintained. As cited in \cite{milojicic02peertopeer}, good scalability should not be achieved by the expense |
|
|
of other desirable features, such as determinism and performance guarantees. |
|
365 |
|
|
366 |
|
\parbox{37pt}{Pastry} & |
367 |
|
\parbox{37pt}{$O(\log^2{n})$} & |
368 |
|
\parbox{37pt}{$O(\log{n})$} & |
369 |
|
\parbox{37pt}{$O(\log{n})$} & |
370 |
|
\parbox{85pt}{$(2^{b - 1})\frac{\log{n}}{b}$, where $b$ is a configurable parameter for tuning digit-fixing properties (routing table)} & |
371 |
|
\parbox{85pt}{System's performance may decrease if nodes are not homogeneous and nodes join and leave the system in a dynamic manner, based on Plaxton's algorithm} |
372 |
|
\\ \hline |
373 |
|
|
374 |
|
|
375 |
|
\parbox{37pt}{PeerNet} & |
376 |
|
\parbox{37pt}{$O(\log{n})$} & |
377 |
|
\parbox{37pt}{$O(\log{n})$} & |
378 |
|
\parbox{37pt}{$O(\log{n})$} & |
379 |
|
\parbox{85pt}{$O(\log{n})$} & |
380 |
|
\parbox{85pt}{Operates at network layer} |
381 |
|
\\ \hline |
382 |
|
|
383 |
Anonymity and Autonomy\ |
\parbox{37pt}{Plaxton} & |
384 |
Self-organization\ |
\parbox{37pt}{No support} & |
385 |
Cost Of ownership\ |
\parbox{37pt}{$O(\log{n})$} & |
386 |
ad-hoc connectivity\ |
\parbox{37pt}{$O(\log{n})$} & |
387 |
accountability\ |
\parbox{85pt}{$O(\log{n})$} & |
388 |
reputation\ |
\parbox{85pt}{Plaxton's algortihm is designed to operate in static environment (e.g., web cache)} |
389 |
|
\\ \hline |
390 |
|
|
391 |
\subsection{Adaptations of Peer-to-Peer} |
\parbox{37pt}{Skip Graphs} & |
392 |
|
\parbox{37pt}{$O(\log{n})$} & |
393 |
|
\parbox{37pt}{$O(\log{n})$} & |
394 |
|
\parbox{37pt}{$O(\log{n})$} & |
395 |
|
\parbox{85pt}{$4r(\log{n}) + (\log{n})$, where r=number of resources provided)} & |
396 |
|
\parbox{85pt}{In this approach, node is treated as 'named resource'; in this approach, \emph{resources} self-organise (opposite to DHTs)} |
397 |
|
\\ \hline |
398 |
|
|
399 |
\subsection{Models of Peer-to-Peer} |
\parbox{37pt}{SkipNet} & |
400 |
|
\parbox{37pt}{$O(\log{n})$} & |
401 |
|
\parbox{37pt}{$O(\log{n})$} & |
402 |
|
\parbox{37pt}{$O(\log{n})$} & |
403 |
|
\parbox{85pt}{$2(\log{n})$} & |
404 |
|
\parbox{85pt}{Partially supports underlying network's locality properties} |
405 |
|
\\ \hline |
406 |
|
|
407 |
\section{Peer-to-Peer file sharing architectures} |
\parbox{37pt}{Social} & |
408 |
|
\parbox{37pt}{$O(1)$} & |
409 |
|
\parbox{37pt}{$O(1)$} & |
410 |
|
\parbox{37pt}{$O(n)$} & |
411 |
|
\parbox{85pt}{Can be 1-10000 connections (aka social connections, connections are permament)} & |
412 |
|
\parbox{85pt}{Connection number depends on node's memory/network capabilities} |
413 |
|
\\ \hline |
414 |
|
|
415 |
\subsection{Flooding broadcast} |
\parbox{37pt}{Symphony} & |
416 |
|
\parbox{37pt}{$O(\log^2{n})$} & |
417 |
|
\parbox{37pt}{$O(\log{n})$} & |
418 |
|
\parbox{37pt}{$O(\log{n})$} & |
419 |
|
\parbox{85pt}{$2k+2+f$, where k = long range connections, 2 = node's neighbors, f = fault-tolerance connections)} & |
420 |
|
\parbox{85pt}{Space can be also $O(1)$. Additional space of $space^2$ can be used as a lookahead list for better performance, not necessarily fault-tolerant because of constant degree of neighbors} |
421 |
|
\\ \hline |
422 |
|
|
423 |
\subsection{Distributed hash table} |
\parbox{37pt}{SWAN} & |
424 |
|
\parbox{37pt}{$O(1)$} & |
425 |
|
\parbox{37pt}{$O(1)$} & |
426 |
|
\parbox{37pt}{$O(\log^2{n})$} & |
427 |
|
\parbox{85pt}{$r(2b+2s+2l)$ (where r=number of resources provided, b=boot connections, s=short range connections, l=long range connections), typical connection configuration: 2*(6+7+8)=36} & |
428 |
|
\parbox{85pt}{In this approach, node is treated as 'named resource'; in this approach, \emph{resources} self-organise (opposite to DHTs)} |
429 |
|
\\ \hline |
430 |
|
|
|
In Distributed Hash Table (DHT) approach, each value is associated with a unique key (e.g. SHA-1 \cite{fips-sha-1})in an m-bit virtual address space. The virtual |
|
|
address space is partitioned into sections, which form adjoining regions of this address space. In general, |
|
|
either a single computer or multiple computers is assigned to each section of the virtual address space. Each |
|
|
computer is assigned one or more sections, and they maintains copies of those key-value bindings whose key values |
|
|
lie within its assigned cell. This means, in general, that computer that hosts corresponding key-value pair, |
|
|
is not owned by the user that decided to provide the resource to the netowork. Moreover, the allocation of the address |
|
|
space and the assigment of computers to sections is dynamic. Therefore, everytime when a node joins or |
|
|
leaves the network, the address space is reallocated. |
|
431 |
|
|
432 |
\subsection{Hybrid architecture} |
\parbox{37pt}{Tapestry} & |
433 |
|
\parbox{37pt}{$O(\log^2{n})$} & |
434 |
|
\parbox{37pt}{$O(\log{n})$} & |
435 |
|
\parbox{37pt}{$O(\log{n})$} & |
436 |
|
\parbox{85pt}{$(2^{b - 1})\frac{\log{n}}{b}$, where $b$ is a configurable parameter for tuning digit-fixing properties (routing table)} & |
437 |
|
\parbox{85pt}{System's performance may decrease if nodes are not homogeneous and nodes join and leave the system in a dynamic manner, based on Plaxton's algorithm} |
438 |
|
\\ \hline |
439 |
|
|
440 |
\subsection{Tree based architecture} |
\parbox{37pt}{Viceroy} & |
441 |
|
\parbox{37pt}{$O(\log{n})$} & |
442 |
|
\parbox{37pt}{$O(1)$} & |
443 |
|
\parbox{37pt}{$O(\log{n})$} & |
444 |
|
\parbox{85pt}{11} & |
445 |
|
\parbox{85pt}{System's performance may decrease if nodes are not homogeneous and nodes join and leave the system in a dynamic manner, not necessarily fault-tolerant because of constant degree of neighbors} |
446 |
|
\\ \hline |
447 |
|
|
|
\subsection{Small World Networks} |
|
448 |
|
|
449 |
|
\end{longtable} |
450 |
|
|
451 |
|
Insert/Delete: |
452 |
|
Number of messages when a node joins or leaves the network. |
453 |
|
|
454 |
\subsection{Social discovery architecture} |
Space: |
455 |
|
Space required for a node's neighbors |
456 |
|
|
457 |
\section{Open problems in Peer-to-Peer file sharing} |
Search: |
458 |
|
Number of messages when an object lookup is performed |
459 |
|
|
460 |
\subsection{Scalability} |
\subsection{Differences} |
461 |
|
|
|
\subsection{Resource discovery} |
|
462 |
|
|
463 |
\subsection{Performance} |
\scriptsize |
464 |
|
\begin{longtable}{|l|l|l|} |
465 |
|
\caption[Comparison of Broadicasting and Structured approaches]{Comparison of Broadicasting and Structured approaches} |
466 |
|
\label{table_comparison_approach} \\ |
467 |
|
|
468 |
|
\hline |
469 |
|
\multicolumn{1}{|c|}{\textbf{Property}} & |
470 |
|
\multicolumn{1}{c|}{\textbf{Unstructured}} & |
471 |
|
\multicolumn{1}{c|}{\textbf{Structured}} |
472 |
|
|
473 |
|
\\ \hline |
474 |
|
\endfirsthead |
475 |
|
|
476 |
|
\multicolumn{3}{c}% |
477 |
|
{{\tablename\ \thetable{} -- continued from previous page}} \\ |
478 |
|
\hline |
479 |
|
\multicolumn{1}{|c|}{\textbf{Property}} & |
480 |
|
\multicolumn{1}{c|}{\textbf{Unstructured}} & |
481 |
|
\multicolumn{1}{c|}{\textbf{Structured}} |
482 |
|
\\ \hline |
483 |
|
\endhead |
484 |
|
|
485 |
|
\endfoot |
486 |
|
|
487 |
|
|
488 |
|
|
489 |
|
\parbox{90pt}{Queries} & |
490 |
|
\parbox{100pt}{Uncontrolled} & |
491 |
|
\parbox{100pt}{Controlled} |
492 |
|
\\ \hline |
493 |
|
|
494 |
|
\parbox{90pt}{A way for performing queries} & |
495 |
|
\parbox{100pt}{Keywords} & |
496 |
|
\parbox{100pt}{Exact keys} |
497 |
|
\\ \hline |
498 |
|
|
499 |
|
\parbox{90pt}{Query traffic} & |
500 |
|
\parbox{100pt}{$O(n)/O(n^{2})$} & |
501 |
|
\parbox{100pt}{$O(1)/O(log n)$} |
502 |
|
\\ \hline |
503 |
|
|
504 |
|
\parbox{90pt}{Guaranteed data lookup} & |
505 |
|
\parbox{100pt}{Not necessarily} & |
506 |
|
\parbox{100pt}{Yes} |
507 |
|
\\ \hline |
508 |
|
|
509 |
|
\parbox{90pt}{Overlay's structure} & |
510 |
|
\parbox{100pt}{Uncontrolled and ad hoc} & |
511 |
|
\parbox{100pt}{Controlled and structured} |
512 |
|
\\ \hline |
513 |
|
|
514 |
|
\parbox{90pt}{Max. number of nodes} & |
515 |
|
\parbox{100pt}{Millions} & |
516 |
|
\parbox{100pt}{Billions} |
517 |
|
\\ \hline |
518 |
|
|
519 |
|
\parbox{90pt}{Data placement} & |
520 |
|
\parbox{100pt}{Local} & |
521 |
|
\parbox{100pt}{Not local} |
522 |
|
\\ \hline |
523 |
|
|
524 |
|
\parbox{90pt}{Support for heterogeneity} & |
525 |
|
\parbox{100pt}{Yes} & |
526 |
|
\parbox{100pt}{No} |
527 |
|
\\ \hline |
528 |
|
|
529 |
|
\parbox{90pt}{Support for locality} & |
530 |
|
\parbox{100pt}{Yes} & |
531 |
|
\parbox{100pt}{Partial} |
532 |
|
\\ \hline |
533 |
|
|
534 |
|
\parbox{90pt}{Possibility for routing hotspots} & |
535 |
|
\parbox{100pt}{No} & |
536 |
|
\parbox{100pt}{Yes} |
537 |
|
\\ \hline |
538 |
|
|
539 |
|
\parbox{90pt}{Design/Implementation complexity} & |
540 |
|
\parbox{100pt}{Low} & |
541 |
|
\parbox{100pt}{High} |
542 |
|
\\ \hline |
543 |
|
|
544 |
\subsection{Security} |
\parbox{90pt}{Fault-tolerant} & |
545 |
|
\parbox{100pt}{High} & |
546 |
|
\parbox{100pt}{High} |
547 |
|
\\ \hline |
548 |
|
|
549 |
\subsection{Interoperability} |
\end{longtable} |
550 |
|
|
551 |
|
|
552 |
|
|
|
\chapter{Summary of existing Peer-to-Peer systems} |
|
553 |
|
|
|
This section reviews briefly existing algorithms used in existing Peer-to-Peer systems. Note that this section |
|
|
is not meant to be an exhaustive survey of Peer-to-Peer systems. Instead, this section introduces a few systems |
|
|
from each architectural perspective. |
|
554 |
|
|
555 |
\section{Plaxton} |
\chapter{Open Problems in Peer-to-Peer} |
|
Plaxton \cite{plaxton97accessingnearby} developed the first routing algorithm, which can be used with DHTs. |
|
|
The algorithm is not designed to be used in dynamic distributed systems, because Plaxton algorithm |
|
|
assumes a proportional static node population. However, algorithm provides very efficient routing for search |
|
|
lookups. In Plaxton's approach, the routing works as follows: if a node number e.g. 88768 received a lookup with key |
|
|
88797, which matches the first three digits, then the routing algorithm forwards the query to a node which matches |
|
|
the first four digits. To accomplish this, a each node forwards a packet to a neighbor whose label matches (from left |
|
|
to right) incrementally the destination label in one more digit than its own label does. For a system with $n$ nodes, |
|
|
Plaxton's algorithm routes in $O(log n)$ hops and requires a routing table size of $O(log n)$. |
|
|
|
|
556 |
|
|
557 |
\section{Tapestry} |
\section{Security problems in Peer-to-Peer} |
|
Tapestry \cite{zhao01tapestry} is a adaption of Plaxton's algorithm \cite{plaxton97accessingnearby}. As in Plaxton's approach, |
|
|
each node has a identifier. In addition to Plaxton algorithm, Tapestry has better fault handling and support for dynamic |
|
|
peers. In Tapestry, using IP addresses as node identifiers make the overlay network topology rather similar to the real |
|
|
network topology, because IP addresses ``enough close'' to each other share some length of the same prefix. Therefore, |
|
|
the latency of the query (messages) hop is minimal. Tapestry routes queries with path lengths of $O(log n)$, and each node, |
|
|
for a systems with $n$ nodes, maintains routing table size of $O(log n)$. When a node leaves or joins to network, |
|
|
$O(log^2 n)$ messages are required. |
|
558 |
|
|
559 |
\section{Pastry} |
\section{Miscellaneous problems in Peer-to-Peer} |
|
In Pastry \cite{rowston01pastry}, the key space is considered as a virtual circle. Each node is responsible for keys |
|
|
which are closest numerically. The neighbors consist of leaf set, which is the set of $|L|$ closest nodes. In addition, |
|
|
Pastry has another set of neighbors randomly spread out in the key space for more efficient routing. As in Plaxton approach, |
|
|
Pastry also forwards the query to the neighbor which have the longest shared prefix of the key. Pastry routes within |
|
|
the pathlength of $O(log n)$, each node has $O(log n)$ neighbors and departure or joining of node requires $(log^2 n)$ messages. |
|
560 |
|
|
561 |
\section{CAN} |
\section{Performance and usability problems in Peer-to-Peer} |
|
In the CAN model \cite{ratnasamy01can}, nodes are mapped into a virtual $d$-dimensional coordinate key space. Each node |
|
|
is associated with a hypercubal blocks of this keyspace and every block keeps information on its immediate hypercubal |
|
|
neighbors. In CAN, nodes have $O(d)$ neighbors and expected pathlengths are $O(dn^\frac{1}{d})$. Node insertion or deletion affects |
|
|
$O(number of dimensions)$ existing nodes. Setting $d = log_2(n)/2$, CAN provides similar scalability as Plaxton approach. |
|
562 |
|
|
563 |
\section{Chord} |
\cite{harren02complex} |
564 |
Chord \cite{stoica01chord} uses virtual circle as the key space. As Pastry, Chord also threats node's neighbors as leaf sets. |
|
565 |
However, in Chord, there are two sets of neighbors: each node has a successor list of k nodes which immediately follows the node |
\cite{ratnasamy02routing} |
566 |
in the key space. For better efficiency, each node has additional finger list of $O(log n)$ nodes placed around the key space. |
|
567 |
In a $n$ node network, each node maintains information about $O(log n)$ neighbors, and a lookup is performed within $O(log n)$ |
\cite{hildrum02distributedobject} |
568 |
hops. Additionally in Chord, a node join or leave requires $O(log^2 n)$ messages. |
|
569 |
|
\cite{oram01harnessingpower} |
570 |
|
|
571 |
|
\cite{sloppy:iptps03} |
572 |
|
|
573 |
|
\cite{yang02improvingsearch} |
574 |
|
|
575 |
|
\cite{daswani03openproblems} |
576 |
|
|
577 |
|
\cite{sit02securitycons} |
578 |
|
|
579 |
|
\cite{lv02searchreplication} |
580 |
|
|
581 |
|
\cite{libennowell01observations} |
582 |
|
|
583 |
|
\cite{krishnamurthy01earlymeasurements} |
584 |
|
|
585 |
|
\cite{golle01incentivesp2p} |
586 |
|
|
587 |
\section{Kademlia} |
\cite{karger02findingnearest} |
588 |
|
|
589 |
Kademlia \cite{maymounkov02kademlia} is based on a XOR-based metric topology. In this approach, every query (message) exchanged conveys |
\cite{cornelli02reputableservents} |
|
useful contact information. Furthermore, Kademlia uses this information to send parallel query messages. XOR-metrics are used to calculate |
|
|
distances between points in key space. XOR is symmetric, allowing nodes to receive lookup queries from the same distribution of nodes |
|
|
contained in the key space. Routing table contains ``contact buckets'', which allows to accommodate temporarily used nodes more |
|
|
efficiently than other DHT approaches. For a system with $n$ nodes, Kademlia's algorithm routes in $O(log n)$ hops and requires |
|
|
a routing table size of $O(log n)$. |
|
|
|
|
|
\section{Coral} |
|
|
|
|
|
Coral [NOTYETPUBLISHED] is based on a new abstraction called distributed sloppy hash table (DSHT) and is a layer on existing |
|
|
lookup systems, such as Chord, CAN, Kademlia, Pastry and Tapestry. In contrast to original DHTs, Coral provides a lookup, which |
|
|
is based on name (instead of hash value). Furthermore, Coral aims to avoid DHTs' hot spots and to find nearby data without querying |
|
|
distant nodes. DSHTs sacrifice the consistency of DHTs to support both frequent fetches and frequent stores of the same hash table |
|
|
key. Moreover, the fundamental observation is that a node doesn't need to know every replicated location of a resource---it only |
|
|
needs a single nearby copy. |
|
|
|
|
|
\section{Gnutella} |
|
|
Gnutella \cite{gnutellaurl} is a flooding broadcast file-sharing system which treats all nodes in the network functionally equivalent. Each peer tries to maintain |
|
|
a small number of active connections to its neighbor. These peers are selected from a locally maintained host catcher list, which contains |
|
|
the addresses of the neighbor peers. Gnutella uses a Breadt-First-Search (BFS) traversal with depth limit L, where L is the system-wide maximum TTL |
|
|
of a message in hops. Every node receiving a query will forward the message to all of its neighbour nodes, unless the message has |
|
|
reached the TTL limit. Therefore query results are fast, because BFS sends queries to every possible nodes. However, this approach wastes |
|
|
resources, since BFS sends queries to every possible neighbor nodes. |
|
|
|
|
|
\section{Gnutella2} |
|
|
Gnutella2 \cite{gnutella2url} is a second generation flooding broadcast file-sharing system. As FasTrack, Gnutella2 uses ``Super nodes'' for better scalability. In contrast |
|
|
to FastTrack, Gnutella2 is an open techology. The Gnutella2 system contains four logical levels: new protocol, new data transport architecture, new base services |
|
|
(including search) and an implementation standard. Unfortunately, currently there are no full specifications about Gnutella2 available yet. However, |
|
|
Shareaza \cite{shareazaurl} file-sharing application supports Gnutella2 technology. More text needed !?!? |
|
|
|
|
|
|
|
|
\section{YAPPERS} |
|
|
YAPPERS (Yet Another Peer-to-Peer System) \cite{ganesan02yappers} is hybrid peer-to-peer system. YAPPERS operates on top of an arbitrary overlay network |
|
|
, such as Gnutella, while providing DHT-like search efficiency. Furthermore, in YAPPERS approach, many small DHTs are built instead |
|
|
of one imposing DHT structure. YABBERS divides a large overlay network into many small neighborhoods. The data within each neighborhood is partiotioned among |
|
|
other neighbors like a regular DHT. Lookup queries relies on forwarding mechanism, similar to Gnutella-style flooding, to traverse all the small |
|
|
DHTs in the network. Specifically, within node's immediate neighborhood, YAPPERS behaves like a DHTs. When using extended lookup outside of immediate |
|
|
neighborhood, YAPPERS behaves like Gnutella, but with more intelligence. |
|
|
|
|
|
|
|
|
\section{FastTrack} |
|
|
FastTrack \cite{fasttrackurl} is another hybrid peer-to-peer system. FastTrack is based on flooding broadcast technique, but in contrast to Gnutella, |
|
|
it solves some of the Gnutella's scalability issues by introducing ``Super nodes''. A SuperNode acts like a local hub, building an index |
|
|
of the resources being shared by each node connected to it and proxying lookup queries on behalf of other nodes. This kind of structure reduces |
|
|
network traffic in comparison to a original broadcast query algorithm employed on the Gnutella system. There are many peer-to-peer file-sharing applications |
|
|
which uses FastTrack, such as Morpheus and Kazaa \cite{morpheusurl, kazaaurl}. |
|
|
|
|
|
\section{JXTA} |
|
|
JXTA \cite{jxtaurl} is an open colloboration platform which supports a wide range of distributed applications. The goal of JXTA is provide a general |
|
|
network programming infrastructure. JXTA consists of multiple layers, including core mechanisms, higher level services and number of |
|
|
basic applications. Additionally, at the highest abstraction level, JXTA is a set of protocols. Each protocol is defined by one or more messages |
|
|
exchanged among partisipants of the protocol. Furthermore, each message has also a predefined format, and may include various data fields \cite{jxtaoverview}. |
|
|
|
|
|
\section{SWAN} |
|
|
SWAN (Small World Adaptive Networks) \cite{bonsma02swan} relies heavily on Small World Networks (SWN) \cite{kleinberg99small, nips02-Kleinberg}. SWAN systems consists of |
|
|
named resources which all have an address. In addition to address, each named resource has a binary identity associated with it, which is independent of its address. |
|
|
Each named resource has a unique position in a k-dimensional identity space, based on identity's value. |
|
|
|
|
|
In SWAN, euclidean distance is used to calculate distances in the identity space. As required by SWN theory for proper link distribution, each node has several links |
|
|
to other nodes. All links are uni-directional and are created locally, storing the the identity and address of another named resource. For a systems with $n$ nodes, |
|
|
SWAN's algorithm routes in $O(log n)$ hops and the total number of links per named resource does not depend on $n$. |
|
|
|
|
|
\section{Freenet} |
|
|
Freenet \cite{clarke00freenet} is an example of selective forwarding architecture. In this approach, Milgram's \cite{milgram67smallworld} small-world |
|
|
phenomenon is a fundamental factor. Freenet lookup queries are forwarded from one node to the next according node's local decisions. The decision is based on |
|
|
which one of node's neighbors make the most progress towards target node. For the lookup algorithm to work proprely, two properties must hold \cite{oram01harnessingpower}. |
|
|
First, the Freenet overlay network graph must connected in that way, so that any query eventually reach at least one node where the resource is located. |
|
|
Second, regardless of the number of nodes, short links must exist between any two arbitrary nodes. This makes possible to pass queries between nodes in |
|
|
reasonable of hops in small-world networks, as proposed by Kleingberg \cite{kleinberg99small, nips02-Kleinberg}, Adamic \cite{adamic99small} |
|
|
and others \cite{zhang02using}. |
|
|
|
|
|
\section{Alpine} |
|
|
ALPINE \cite{alpineurl} uses an adaptive social discovery mechanism to implement lookup queries. In Alpine network, nodes (users) continually discover |
|
|
new nodes to communicate with and determine which properties each node have. More important, every node has a total control over the connections in the |
|
|
network. With every lookup query, a node determines how proficient a given node is to another node's objectives. The resource discovery in Alpine is |
|
|
performed by sending queries only nodes who have a connection to a source node. To better lookup efficiency, profile operation associated with each node |
|
|
is used to evaluate the order in which each is sent a query. As in real social life, nodes who have returned relevant results in the past, will have a high |
|
|
quality value in future query lookups. |
|
|
|
|
|
|
|
|
\section{Future directions} |
|
|
|
|
|
Since peer-to-peer concept was reinvented by Napster \cite{napsterurl} a few years ago, great amount of peer-to-peer systems have been introduced. |
|
|
Furthermore, the majority of these systems are unable to interoperate together. According to recent seminar \cite{uclaseminar}, held in the University of UCLA, |
|
|
there are few projects that analyse systems' different approaches. However, the most important question is that how existing approaches can be combined into one |
|
|
practical and high performance approach, currently known as ``Gnutella++''. |
|
590 |
|
|
591 |
\chapter{Open Problems in P2P} |
\cite{aberer01trust} |
592 |
|
|
593 |
|
\cite{adamic02localsearch} |
594 |
|
|
595 |
|
\cite{adamic01powerlawsearch} |
596 |
|
|
597 |
|
\cite{saroiu02measurementstudyp2p} |
598 |
|
|
599 |
|
\cite{ripeanu02mappinggnutella} |
600 |
|
|
601 |
|
\cite{kronfol02fasdsearch} |
602 |
|
|
603 |
|
\cite{brinkmann02compactplacement} |
604 |
|
|
605 |
|
\cite{ajmani02conchord} |
606 |
|
|
607 |
|
\cite{362692} |
608 |
|
|
609 |
|
\cite{CuencaAcuna2002DSIWorkshop} |
610 |
|
|
611 |
|
\cite{reiter98crowds} |
612 |
|
|
613 |
|
\cite{352607} |
614 |
|
|
615 |
|
\cite{293447} |
616 |
|
|
617 |
|
\cite{tarzan:ccs9} |
618 |
|
|
619 |
|
\cite{pub00} |
620 |
|
|
621 |
|
\cite{rhea02probabilistic} |
622 |
|
|
623 |
|
\cite{502002} |
624 |
|
|
625 |
|
%dup |
626 |
|
\cite{castro02securitystructured} |
627 |
|
\cite{castro02securerouting} |
628 |
|
|
629 |
|
\cite{zhao02brocade} |
630 |
|
|
631 |
|
\cite{datar02butterflies} |
632 |
|
|
633 |
|
\cite{crespo02semanticoverlay} |
634 |
|
|
635 |
|
\cite{lv02gnutellascalable} |
636 |
|
|
637 |
|
\cite{keleher-02-p2p} |
638 |
|
|
639 |
|
\cite{saia02dynamicfaultcontentnetwork} |
640 |
|
|
641 |
|
\cite{yang02efficientsearch} |
642 |
|
|
643 |
|
%dup |
644 |
|
\cite{liben-nowell02observatorionsp2p} |
645 |
|
\cite{571863} |
646 |
|
|
647 |
|
\cite{lynch02atomicdataaccess} |
648 |
|
|
649 |
|
\cite{yang02comparinghybrid} |
650 |
|
|
651 |
|
\cite{ledlie02selfp2p} |
652 |
|
|
653 |
|
\cite{frise02p2pframework} |
654 |
|
|
655 |
|
\cite{joseph02p2players} |
656 |
|
|
657 |
|
\cite{andrzejak02rangequeries} |
658 |
|
|
659 |
|
\cite{babaoglu02anthill} |
660 |
|
|
661 |
|
\cite{fiat02censorship} |
662 |
|
|
663 |
|
\cite{hearn02mojonation} |
664 |
|
|
665 |
|
\cite{osokine02distnetworks} |
666 |
|
|
667 |
|
\cite{harvey03skipnet1} |
668 |
|
|
669 |
|
\cite{ansaryefficientbroadcast03} |
670 |
|
|
671 |
|
\cite{ng02predicting} |
672 |
|
|
673 |
|
\cite{douceur02sybil} |
674 |
|
|
675 |
|
\cite{castro02networkproximity} |
676 |
|
|
677 |
|
\cite{296824} |
678 |
|
|
679 |
|
\cite{juels99clientpuzzles} |
680 |
|
\cite{357176} |
681 |
|
|
682 |
|
\cite{grahamp2psecurity} |
683 |
|
|
684 |
|
\cite{zhao03api} |
685 |
|
|
686 |
|
\cite{nejdl03accesscontrol} |
687 |
|
|
688 |
|
\cite{bhagwan03availability} |
689 |
|
|
690 |
|
\cite{li03feasibility} |
691 |
|
|
692 |
|
\cite{zhang03somo} |
693 |
|
|
694 |
|
\cite{rao03loadbalancing} |
695 |
|
|
696 |
|
\cite{rhea03benchmarks} |
697 |
|
|
698 |
|
\cite{chord:om_p-meng} |
699 |
|
|
700 |
|
\section{Summary} |
701 |
|
|
702 |
\scriptsize |
\scriptsize |
703 |
\begin{longtable}{|l|l|l|l|} |
\begin{longtable}{|l|l|l|l|} |
704 |
\caption[Security problems in P2P]{Security problems in P2P} \label{table_security_problems_p2p} \\ |
\caption[Security problems in Peer-to-Peer]{Security problems in Peer-to-Peer} \label{table_security_problems_Peer-to-Peer} \\ |
705 |
|
|
706 |
|
|
707 |
|
|
790 |
|
|
791 |
|
|
792 |
\parbox{90pt}{Access Control} & |
\parbox{90pt}{Access Control} & |
793 |
\parbox{110pt}{Can we define access control levels in peer-to-peer network ?} & |
\parbox{110pt}{Can we define access control levels in Peer-to-Peer network ?} & |
794 |
\parbox{110pt}{Schema-based rules} & |
\parbox{110pt}{Schema-based rules} & |
795 |
\parbox{110pt}{Some initial experiences, need more research} |
\parbox{110pt}{Some initial experiences, need more research} |
796 |
\\ \hline |
\\ \hline |
820 |
\end{longtable} |
\end{longtable} |
821 |
|
|
822 |
|
|
823 |
|
|
824 |
|
|
825 |
|
|
826 |
\begin{longtable}{|l|l|l|l|} |
\begin{longtable}{|l|l|l|l|} |
827 |
\caption[Performance and usability problems in P2P]{Performance and usability problems in P2P} \label{table_performanceusability_problems_p2p} \\ |
\caption[Performance and usability problems in Peer-to-Peer]{Performance and usability problems in Peer-to-Peer} \label{table_performanceusability_problems_Peer-to-Peer} \\ |
828 |
|
|
829 |
|
|
830 |
\hline |
\hline |
931 |
\end{longtable} |
\end{longtable} |
932 |
|
|
933 |
|
|
934 |
|
|
935 |
|
|
936 |
\begin{longtable}{|l|l|l|l|} |
\begin{longtable}{|l|l|l|l|} |
937 |
\caption[Miscellaneous problems in P2P]{Miscellaneous problems in P2P} \label{table_Miscellaneous_problems_p2p} \\ |
\caption[Miscellaneous problems in Peer-to-Peer]{Miscellaneous problems in Peer-to-Peer} \label{table_Miscellaneous_problems_Peer-to-Peer} \\ |
938 |
|
|
939 |
|
|
940 |
\hline |
\hline |
1005 |
\\ \hline |
\\ \hline |
1006 |
|
|
1007 |
|
|
1008 |
\parbox{90pt}{Comprehensive simulations/analysis of peer-to-peer network} & |
\parbox{90pt}{Comprehensive simulations/analysis of Peer-to-Peer network} & |
1009 |
\parbox{110pt}{Ability to simulate whole p2p network's usage patterns, network traffics, flux state etc} & |
\parbox{110pt}{Ability to simulate whole Peer-to-Peer network's usage patterns, network traffics, flux state etc} & |
1010 |
\parbox{110pt}{Use same techniques as simulating/analysing the Internet} & |
\parbox{110pt}{Use same techniques as simulating/analysing the Internet} & |
1011 |
\parbox{110pt}{Only small subset of peer-to-peer networks has been able to analyse, because of ad hoc properties of network, more poweful solutions needed} |
\parbox{110pt}{Only small subset of Peer-to-Peer networks has been able to analyse, because of ad hoc properties of network, more poweful solutions needed} |
1012 |
\\ \hline |
\\ \hline |
1013 |
|
|
1014 |
|
|
1018 |
\parbox{110pt}{For structured overlays, efficient and simple to implement, fault-tolerance unknowns, for unstructured, not necessarily efficient because decisions are based on local knowledge} |
\parbox{110pt}{For structured overlays, efficient and simple to implement, fault-tolerance unknowns, for unstructured, not necessarily efficient because decisions are based on local knowledge} |
1019 |
\\ \hline |
\\ \hline |
1020 |
|
|
1021 |
\parbox{90pt}{Locating peer-to-peer network} & |
\parbox{90pt}{Locating Peer-to-Peer network} & |
1022 |
\parbox{110pt}{How old peers or new peers are able to locate peer-to-peer network, if it exists} & |
\parbox{110pt}{How old peers or new peers are able to locate Peer-to-Peer network, if it exists} & |
1023 |
\parbox{110pt}{Servers maintaining online peers (e.g. gnutellahosts.com), peer's history information} & |
\parbox{110pt}{Servers maintaining online peers (e.g. gnutellahosts.com), peer's history information} & |
1024 |
\parbox{110pt}{Depends on implementation and purpose of the system, for mobile ad hoc networks more research is needed} |
\parbox{110pt}{Depends on implementation and purpose of the system, for mobile ad hoc networks more research is needed} |
1025 |
\\ \hline |
\\ \hline |
1031 |
|
|
1032 |
|
|
1033 |
|
|
|
\begin{longtable}{|l|l|l|} |
|
|
\caption[Comparison of Broadicasting and Structured approaches]{Comparison of Broadicasting and Structured approaches} |
|
|
\label{table_comparison_approach} \\ |
|
|
|
|
|
\hline |
|
|
\multicolumn{1}{|c|}{\textbf{Property}} & |
|
|
\multicolumn{1}{c|}{\textbf{Unstructured}} & |
|
|
\multicolumn{1}{c|}{\textbf{Structured}} |
|
|
|
|
|
\\ \hline |
|
|
\endfirsthead |
|
|
|
|
|
\multicolumn{3}{c}% |
|
|
{{\tablename\ \thetable{} -- continued from previous page}} \\ |
|
|
\hline |
|
|
\multicolumn{1}{|c|}{\textbf{Property}} & |
|
|
\multicolumn{1}{c|}{\textbf{Unstructured}} & |
|
|
\multicolumn{1}{c|}{\textbf{Structured}} |
|
|
\\ \hline |
|
|
\endhead |
|
|
|
|
|
\endfoot |
|
|
|
|
|
|
|
|
|
|
|
\parbox{90pt}{Queries} & |
|
|
\parbox{100pt}{Uncontrolled} & |
|
|
\parbox{100pt}{Controlled} |
|
|
\\ \hline |
|
|
|
|
|
\parbox{90pt}{A way for performing queries} & |
|
|
\parbox{100pt}{Keywords} & |
|
|
\parbox{100pt}{Exact keys} |
|
|
\\ \hline |
|
|
|
|
|
\parbox{90pt}{Query traffic} & |
|
|
\parbox{100pt}{$O(n)/O(n^{2})$} & |
|
|
\parbox{100pt}{$O(1)/O(log n)$} |
|
|
\\ \hline |
|
|
|
|
|
\parbox{90pt}{Guaranteed data lookup} & |
|
|
\parbox{100pt}{Not necessarily} & |
|
|
\parbox{100pt}{Yes} |
|
|
\\ \hline |
|
|
|
|
|
\parbox{90pt}{Overlay's structure} & |
|
|
\parbox{100pt}{Uncontrolled and ad hoc} & |
|
|
\parbox{100pt}{Controlled and structured} |
|
|
\\ \hline |
|
|
|
|
|
\parbox{90pt}{Max. number of nodes} & |
|
|
\parbox{100pt}{Millions} & |
|
|
\parbox{100pt}{Billions} |
|
|
\\ \hline |
|
|
|
|
|
\parbox{90pt}{Data placement} & |
|
|
\parbox{100pt}{Local} & |
|
|
\parbox{100pt}{Not local} |
|
|
\\ \hline |
|
|
|
|
|
\parbox{90pt}{Support for heterogeneity} & |
|
|
\parbox{100pt}{Yes} & |
|
|
\parbox{100pt}{No} |
|
|
\\ \hline |
|
|
|
|
|
\parbox{90pt}{Support for locality} & |
|
|
\parbox{100pt}{Yes} & |
|
|
\parbox{100pt}{Partial} |
|
|
\\ \hline |
|
|
|
|
|
\parbox{90pt}{Possibility for routing hotspots} & |
|
|
\parbox{100pt}{No} & |
|
|
\parbox{100pt}{Yes} |
|
|
\\ \hline |
|
|
|
|
|
\parbox{90pt}{Design/Implementation complexity} & |
|
|
\parbox{100pt}{Low} & |
|
|
\parbox{100pt}{High} |
|
|
\\ \hline |
|
|
|
|
|
\parbox{90pt}{Fault-tolerant} & |
|
|
\parbox{100pt}{High} & |
|
|
\parbox{100pt}{High} |
|
|
\\ \hline |
|
|
|
|
|
\end{longtable} |
|
|
|
|
1034 |
|
|
1035 |
|
|
1036 |
|
|
|
\begin{longtable}{|l|c|c|c|c|l|} |
|
|
\caption[Different peer-to-peer lookup protocols]{Different peer-to-peer lookup protocols} |
|
|
\label{table_p2p_protocols} \\ |
|
1037 |
|
|
|
\hline |
|
|
\multicolumn{1}{|c|}{\textbf{Protocol}} & |
|
|
\multicolumn{1}{c|}{\textbf{Insert/Delete}} & |
|
|
\multicolumn{1}{c|}{\textbf{Space}} & |
|
|
\multicolumn{1}{c|}{\textbf{Lookup}} & |
|
|
\multicolumn{1}{c|}{\textbf{\# of network connections}} & |
|
|
\multicolumn{1}{c|}{\textbf{Notes}} |
|
|
\\ \hline |
|
|
\endfirsthead |
|
1038 |
|
|
|
\multicolumn{6}{c}% |
|
|
{{\tablename\ \thetable{} -- continued from previous page}} \\ |
|
|
\hline |
|
|
\multicolumn{1}{|c|}{\textbf{Protocol}} & |
|
|
\multicolumn{1}{c|}{\textbf{Insert/Delete}} & |
|
|
\multicolumn{1}{c|}{\textbf{Space}} & |
|
|
\multicolumn{1}{c|}{\textbf{Lookup}} & |
|
|
\multicolumn{1}{c|}{\textbf{\# of network connections}} & |
|
|
\multicolumn{1}{c|}{\textbf{Notes}} |
|
|
\\ \hline |
|
|
\endhead |
|
1039 |
|
|
|
\endfoot |
|
1040 |
|
|
|
\parbox{37pt}{CAN} & |
|
|
\parbox{37pt}{$O$($d$)} & |
|
|
\parbox{37pt}{$O$($d$)} & |
|
|
\parbox{37pt}{$O(dn^{\frac{1}{d}})$} & |
|
|
\parbox{85pt}{2$d$} & |
|
|
\parbox{85pt}{System's performance may decrease if nodes are not homogeneous and nodes join and leave the system in a dynamic manner, where $d$ is the dimension of virtual key space} |
|
|
\\ \hline |
|
1041 |
|
|
|
\parbox{37pt}{Chord} & |
|
|
\parbox{37pt}{$O(\log^2{n})$} & |
|
|
\parbox{37pt}{$O(\log{n}$} & |
|
|
\parbox{37pt}{$O(\log{n})$} & |
|
|
\parbox{85pt}{2$(\log{n})$} & |
|
|
\parbox{85pt}{System's performance may decrease if nodes are not homogeneous and nodes join and leave the system in a dynamic manner} |
|
|
\\ \hline |
|
1042 |
|
|
1043 |
|
|
|
\parbox{37pt}{Freenet} & |
|
|
\parbox{37pt}{$O(1)$} & |
|
|
\parbox{37pt}{$O(1)$} & |
|
|
\parbox{37pt}{$O(n)$} & |
|
|
\parbox{85pt}{Typical configuration e.g., 4-150} & |
|
|
\parbox{85pt}{Average lookup performance is $O(\log{n})$ with tens of thousands concurrent users, beyond that, the performace is $O(n)$} |
|
|
\\ \hline |
|
|
|
|
|
|
|
|
\parbox{37pt}{Gnutella} & |
|
|
\parbox{37pt}{$O(1)$} & |
|
|
\parbox{37pt}{$O(1)$} & |
|
|
\parbox{37pt}{$O(n)$} & |
|
|
\parbox{85pt}{Typical configuration is 5 connections (2*5=10 total), however, depends on implementation} & |
|
|
\parbox{85pt}{Number of messages can grow as fast as $O(n^{2})$} |
|
|
\\ \hline |
|
|
|
|
|
|
|
|
\parbox{37pt}{Kademlia} & |
|
|
\parbox{37pt}{$O(\log{n})$} & |
|
|
\parbox{37pt}{$O(\log{n})$} & |
|
|
\parbox{37pt}{$O(\log{n})$} & |
|
|
\parbox{85pt}{$2(\log{n})$} & |
|
|
\parbox{85pt}{There is no action required when nodes leaves the system} |
|
|
\\ \hline |
|
|
|
|
|
|
|
|
\parbox{37pt}{Kelips} & |
|
|
\parbox{37pt}{$O(2(\sqrt{n}*(log^2{n})) + (\sqrt{n} + (log^3{n})))$} & |
|
|
\parbox{37pt}{$O$($\sqrt{n}$)} & |
|
|
\parbox{37pt}{$O(1)$} & |
|
|
\parbox{85pt}{$\frac{n}{\sqrt{n}} + c*(\sqrt{n}-1) + \frac{Totalnumber of files}{\sqrt{n}}$, where n is the number of nodes and c the number of contacts/foreign affinity group} & |
|
|
\parbox{85pt}{Insert/delete overhead is constant and performed background, System's performance may decrease if nodes are not homogeneous and nodes join and leave the system in a dynamic manner} |
|
|
\\ \hline |
|
|
|
|
|
\parbox{37pt}{Koorde} & |
|
|
\parbox{37pt}{$O(\log^2{n})$} & |
|
|
\parbox{37pt}{$O(1)$ or $O(\log{n})$} & |
|
|
\parbox{37pt}{$O(\log{n})$ or $O(\frac{\log{n}}{\log{}\log{n}})$} & |
|
|
\parbox{85pt}{$2(\log{n})$} & |
|
|
\parbox{85pt}{Based on Chord protocol, uses de Bruijn graphs for better efficiency/fault-tolerance} |
|
|
\\ \hline |
|
|
|
|
|
\parbox{37pt}{ODHDHT} & |
|
|
\parbox{37pt}{$O(\log{n})$} & |
|
|
\parbox{37pt}{$O(\log{n})$} & |
|
|
\parbox{37pt}{$O(\log{n})$} & |
|
|
\parbox{85pt}{$2(\log{n})$} & |
|
|
\parbox{85pt}{There are two lookup algorithms. The other is $O(\log{n})$, which is robus under random deletion. The second is $O(\log^2{n})$, which is also robust under spam generating model} |
|
|
\\ \hline |
|
|
|
|
|
|
|
|
\parbox{37pt}{Pastry} & |
|
|
\parbox{37pt}{$O(\log^2{n})$} & |
|
|
\parbox{37pt}{$O(\log{n})$} & |
|
|
\parbox{37pt}{$O(\log{n})$} & |
|
|
\parbox{85pt}{$(2^{b - 1})\frac{\log{n}}{b}$, where $b$ is a configurable parameter for tuning digit-fixing properties (routing table)} & |
|
|
\parbox{85pt}{System's performance may decrease if nodes are not homogeneous and nodes join and leave the system in a dynamic manner, based on Plaxton's algorithm} |
|
|
\\ \hline |
|
|
|
|
|
|
|
|
\parbox{37pt}{PeerNet} & |
|
|
\parbox{37pt}{$O(\log{n})$} & |
|
|
\parbox{37pt}{$O(\log{n})$} & |
|
|
\parbox{37pt}{$O(\log{n})$} & |
|
|
\parbox{85pt}{$O(\log{n})$} & |
|
|
\parbox{85pt}{Operates at network layer} |
|
|
\\ \hline |
|
|
|
|
|
\parbox{37pt}{Plaxton} & |
|
|
\parbox{37pt}{No support} & |
|
|
\parbox{37pt}{$O(\log{n})$} & |
|
|
\parbox{37pt}{$O(\log{n})$} & |
|
|
\parbox{85pt}{$O(\log{n})$} & |
|
|
\parbox{85pt}{Plaxton's algortihm is designed to operate in static environment (e.g., web cache)} |
|
|
\\ \hline |
|
|
|
|
|
\parbox{37pt}{Skip Graphs} & |
|
|
\parbox{37pt}{$O(\log{n})$} & |
|
|
\parbox{37pt}{$O(\log{n})$} & |
|
|
\parbox{37pt}{$O(\log{n})$} & |
|
|
\parbox{85pt}{$4r(\log{n}) + (\log{n})$, where r=number of resources provided)} & |
|
|
\parbox{85pt}{In this approach, node is treated as 'named resource'; in this approach, \emph{resources} self-organise (opposite to DHTs)} |
|
|
\\ \hline |
|
|
|
|
|
\parbox{37pt}{SkipNet} & |
|
|
\parbox{37pt}{$O(\log{n})$} & |
|
|
\parbox{37pt}{$O(\log{n})$} & |
|
|
\parbox{37pt}{$O(\log{n})$} & |
|
|
\parbox{85pt}{$2(\log{n})$} & |
|
|
\parbox{85pt}{Partially supports underlying network's locality properties} |
|
|
\\ \hline |
|
|
|
|
|
\parbox{37pt}{Social} & |
|
|
\parbox{37pt}{$O(1)$} & |
|
|
\parbox{37pt}{$O(1)$} & |
|
|
\parbox{37pt}{$O(n)$} & |
|
|
\parbox{85pt}{Can be 1-10000 connections (aka social connections, connections are permament)} & |
|
|
\parbox{85pt}{Connection number depends on node's memory/network capabilities} |
|
|
\\ \hline |
|
|
|
|
|
\parbox{37pt}{Symphony} & |
|
|
\parbox{37pt}{$O(\log^2{n})$} & |
|
|
\parbox{37pt}{$O(\log{n})$} & |
|
|
\parbox{37pt}{$O(\log{n})$} & |
|
|
\parbox{85pt}{$2k+2+f$, where k = long range connections, 2 = node's neighbors, f = fault-tolerance connections)} & |
|
|
\parbox{85pt}{Space can be also $O(1)$. Additional space of $space^2$ can be used as a lookahead list for better performance, not necessarily fault-tolerant because of constant degree of neighbors} |
|
|
\\ \hline |
|
|
|
|
|
\parbox{37pt}{SWAN} & |
|
|
\parbox{37pt}{$O(1)$} & |
|
|
\parbox{37pt}{$O(1)$} & |
|
|
\parbox{37pt}{$O(\log^2{n})$} & |
|
|
\parbox{85pt}{$r(2b+2s+2l)$ (where r=number of resources provided, b=boot connections, s=short range connections, l=long range connections), typical connection configuration: 2*(6+7+8)=36} & |
|
|
\parbox{85pt}{In this approach, node is treated as 'named resource'; in this approach, \emph{resources} self-organise (opposite to DHTs)} |
|
|
\\ \hline |
|
|
|
|
|
|
|
|
\parbox{37pt}{Tapestry} & |
|
|
\parbox{37pt}{$O(\log^2{n})$} & |
|
|
\parbox{37pt}{$O(\log{n})$} & |
|
|
\parbox{37pt}{$O(\log{n})$} & |
|
|
\parbox{85pt}{$(2^{b - 1})\frac{\log{n}}{b}$, where $b$ is a configurable parameter for tuning digit-fixing properties (routing table)} & |
|
|
\parbox{85pt}{System's performance may decrease if nodes are not homogeneous and nodes join and leave the system in a dynamic manner, based on Plaxton's algorithm} |
|
|
\\ \hline |
|
|
|
|
|
\parbox{37pt}{Viceroy} & |
|
|
\parbox{37pt}{$O(\log{n})$} & |
|
|
\parbox{37pt}{$O(1)$} & |
|
|
\parbox{37pt}{$O(\log{n})$} & |
|
|
\parbox{85pt}{11} & |
|
|
\parbox{85pt}{System's performance may decrease if nodes are not homogeneous and nodes join and leave the system in a dynamic manner, not necessarily fault-tolerant because of constant degree of neighbors} |
|
|
\\ \hline |
|
|
|
|
|
|
|
|
\end{longtable} |
|
|
|
|
|
Insert/Delete: |
|
|
Number of messages when a node joins or leaves the network. |
|
|
|
|
|
Space: |
|
|
Space required for a node's neighbors |
|
|
|
|
|
Search: |
|
|
Number of messages when an object lookup is performed |
|
|
|
|
|
\begin{figure} |
|
|
\centering |
|
|
\includegraphics[width=10cm, height=8cm]{application_level_overlay.eps} |
|
|
\caption{P2P Application Level Overlay} |
|
|
\label{fig:application_level} |
|
|
\end{figure} |
|
|
|
|
|
|
|
|
\begin{figure} |
|
|
\centering |
|
|
\includegraphics[width=14cm, height=8cm]{structured_overlay.eps} |
|
|
%\includegraphics[width=14cm, height=8cm]{application_level_overlay.eps} |
|
|
\caption{Generation of structured overlay network} |
|
|
\label{fig:structured_hashing} |
|
|
\end{figure} |
|
|
|
|
|
\begin{figure} |
|
|
\centering |
|
|
\includegraphics[width=6cm, height=6cm]{gnutella_overlay.eps} |
|
|
\caption{Gnutella overlay network} |
|
|
\label{fig:gnutella_overlay} |
|
|
\end{figure} |
|
|
|
|
|
\begin{figure} |
|
|
\centering |
|
|
\includegraphics[width=8cm, height=6cm]{gnutella_overlay_supernodes.eps} |
|
|
\caption{Gnutella overlay network with super nodes} |
|
|
\label{fig:gnutella_overlay_supernodes} |
|
|
\end{figure} |
|
|
|
|
|
\begin{figure} |
|
|
\centering |
|
|
\includegraphics[width=10cm, height=6cm]{gnutella_overlay_clusters.eps} |
|
|
\caption{Gnutella overlay network with 2-redundant super node clusters} |
|
|
\label{fig:gnutella_overlay_cluster} |
|
|
\end{figure} |
|
|
|
|
|
\begin{figure} |
|
|
\centering |
|
|
\includegraphics[width=8cm, height=6cm]{gnutella_query.eps} |
|
|
\caption{Basic Gnutella query} |
|
|
\label{fig:gnutella_query} |
|
|
\end{figure} |
|
|
|
|
|
|
|
|
\begin{figure} |
|
|
\centering |
|
|
\includegraphics[width=8cm, height=6cm]{structured_query.eps} |
|
|
\caption{Simplified structured system's query} |
|
|
\label{fig:structured_query} |
|
|
\end{figure} |
|
|
|
|
1044 |
\begin{figure} |
\begin{figure} |
1045 |
\centering |
\centering |
1046 |
\includegraphics[width=14cm, height=12cm]{xanadu_model.eps} |
\includegraphics[width=14cm, height=12cm]{xanadu_model.eps} |
1056 |
\end{figure} |
\end{figure} |
1057 |
|
|
1058 |
|
|
1059 |
\chapter{Gzz System} |
\chapter{Overview of Gzz} |
|
|
|
|
\section{Overview of Gzz} |
|
1060 |
|
|
1061 |
\section{Objectives} |
\section{Objectives} |
1062 |
|
|
1063 |
\section{Xanalogical model} |
\cite{thompson01hypermedia} |
1064 |
|
\cite{wiil02p2phypertext} |
1065 |
\section{ZigZag hyperstructure} |
\cite{bouvin02openhypermedia} |
1066 |
|
|
1067 |
\subsection{Cells} |
\section{Xanalogical model} |
1068 |
|
|
1069 |
\subsection{Dimensions} |
\cite{nelson99xanalogicalneeded} |
1070 |
|
|
1071 |
\section{Storm} |
\section{Storm} |
1072 |
|
|
1073 |
\subsection{Blocks} |
\cite{lukka02freenetguids} |
1074 |
|
|
1075 |
|
\subsection{Block storage} |
1076 |
|
|
1077 |
|
\cite{benja02urn5} |
1078 |
|
\cite{balakrishnan03semanticfree} |
1079 |
|
|
1080 |
\chapter{Evaluation of Peer-to-Peer for Gzz} |
\chapter{Evaluation of Peer-to-Peer for Gzz} |
1081 |
|
|
1087 |
|
|
1088 |
\section{Special needs} |
\section{Special needs} |
1089 |
|
|
1090 |
|
\cite{bittorrenturl} |
1091 |
|
\cite{maymounkov03ratelesscodes} |
1092 |
|
|
1093 |
\section{Existing file sharing systems and Gzz} |
\section{Existing file sharing systems and Gzz} |
1094 |
|
|
1095 |
\section{Possible problems} |
\section{Possible problems} |
1096 |
|
|
1097 |
|
\cite{gribble01p2pdatabase} |
1098 |
|
|
1099 |
\chapter{Conclusion} |
\chapter{Conclusion} |
1100 |
|
|