/[gzz]/gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
ViewVC logotype

Diff of /gzz/Documentation/misc/hemppah-progradu/masterthesis.tex

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.48 by hemppah, Wed Feb 19 10:55:30 2003 UTC revision 1.49 by hemppah, Wed Feb 19 13:58:16 2003 UTC
# Line 27  Line 27 
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ä\\
# Line 55  sähköposti: hemppah@cc.jyu.fi} Line 55  sähköposti: hemppah@cc.jyu.fi}
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    
# Line 448  practical and high performance approach, Line 790  practical and high performance approach,
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
# Line 478  practical and high performance approach, Line 820  practical and high performance approach,
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
# Line 586  practical and high performance approach, Line 931  practical and high performance approach,
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
# Line 658  practical and high performance approach, Line 1005  practical and high performance approach,
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    
# Line 671  practical and high performance approach, Line 1018  practical and high performance approach,
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
# Line 684  practical and high performance approach, Line 1031  practical and high performance approach,
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}
# Line 1032  Number of messages when an object lookup Line 1056  Number of messages when an object lookup
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    
# Line 1062  Number of messages when an object lookup Line 1087  Number of messages when an object lookup
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    

Legend:
Removed from v.1.48  
changed lines
  Added in v.1.49

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26