/[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.124 by hemppah, Thu Mar 6 10:54:35 2003 UTC revision 1.125 by hemppah, Thu Mar 6 15:12:32 2003 UTC
# Line 27  Line 27 
27    
28  \tyyppi{Master's Thesis}  \tyyppi{Master's Thesis}
29    
30  \keywords{Peer-to-Peer, P2P, security, Distributed systems, Hypermedia systems}  \keywords{Peer-to-Peer, P2P, security, distributed systems, hypermedia systems}
31    
32  \avainsanat{Vertaisverkot, P2P, tietoturva, hajautetut järjestelmät, hypermedia-järjestelmät}  \avainsanat{Vertaisverkot, P2P, tietoturva, hajautetut järjestelmät, hypermedia-järjestelmät}
33    
# Line 92  and services by direct exchange between Line 92  and services by direct exchange between
92  Dave Winer \cite{winer00whatisp2p} lists several  Dave Winer \cite{winer00whatisp2p} lists several
93  properties of Peer-to-Peer network, while most notably the statement  properties of Peer-to-Peer network, while most notably the statement
94  ''The user's machine is a client and a server'' describes best Peer-to-Peer  ''The user's machine is a client and a server'' describes best Peer-to-Peer
95  networks. To summarize, Peer-to-Peer systems can be characterized as distributed  systems. To summarize, Peer-to-Peer systems can be characterized as distributed
96  systems in which all communication is symmetric and all participants have identical  systems in which all communication is symmetric and all participants have identical
97  capabilities and responsabilities. Each \emph{peer} may contribute data or  capabilities and responsabilities. Each \emph{peer} may contribute data or
98  computing resources (e.g., unused storage) to the overall system and the welfare  computing resources (e.g., unused storage) to the overall system and the welfare
99  of the community can scale with ne number of participants. Thus, each participant  of the community can scale with the number of participants. Thus, each participant
100  rely on one another services and resources, rather than solely relying on dedicated  rely on one another's services and resources, rather than solely relying on dedicated
101  and centralized infracstructure.  and centralized infracstructure.
102    
103  One of the most important properties of any distributed computing system are efficient  One of the most important properties of any distributed computing system are efficient
# Line 105  data lookup and security. In this thesis Line 105  data lookup and security. In this thesis
105  focus on these aspects in Peer-to-Peer domain.  focus on these aspects in Peer-to-Peer domain.
106  Specifically, we review existing Peer-to-Peer approaches, algorithms and their key properties. We observe  Specifically, we review existing Peer-to-Peer approaches, algorithms and their key properties. We observe
107  that despite of greate amount of proposed Peer-to-Peer systems, all systems fall either  that despite of greate amount of proposed Peer-to-Peer systems, all systems fall either
108  loosely structured approach or tightly structured approach. Then, we discuss open problems in  loosely structured approach or tightly structured approach. We also discuss open problems in
109  Peer-to-Peer networks and divide problems into three sub-categories: security related problems,  Peer-to-Peer networks and divide problems into three sub-categories: security related problems,
110  performance related problems and miscellaneous problems. In the end, we summarize all  performance related problems and miscellaneous problems. In the end, we summarize all
111  problems in easy-to-understand tables.  problems in easy-to-understand tables.
112    
113  Next, we give an overview of our Fenfire system, which implements xanalogical storage model. We  Next, we give an overview of our Fenfire hypermedia system, which implements xanalogical storage model. We
114  also describe briefly Storm software module, which is an essential part of Fenfire's  also describe briefly Storm software module of Fenfire system, which is an essential part of Fenfire's
115  Peer-to-Peer functionality. We evaluate existing Peer-to-Peer approaches and  Peer-to-Peer functionality. We evaluate existing Peer-to-Peer approaches and
116  choose the best alternative to our needs. We discover that Storm, xanalogical model and  choose the best alternative to our needs. We discover that Fenfire, xanalogical model and
117  tightly structured Peer-to-Peer approach all have similar method to deal with data,  tightly structured Peer-to-Peer approach all have similar method to deal with data,
118  i.e., globally unique identifiers. Finally, we propose yet simple but effective  i.e., globally unique identifiers. Finally, we propose system model for Fenfire in Peer-to-Peer
119  algortihms to be used  with our Fenfire system in Peer-to-Peer environment.  environment and present yet simple but efficient algortihms to be used for data lookups in
120    Peer-to-Peer environment.
121    
122  To our knowledge, this thesis is the most comprehensive work with regard to summarizing  To our knowledge, this thesis is the most comprehensive work with regard to summarizing
123  existing Peer-to-Peer algorithms and open problems in Peer-to-Peer domain. However, this  existing algorithms and open problems in Peer-to-Peer domain. However, this
124  thesis is not meant to be detailed work. More detailed information can be found from genuine  thesis is not meant to be detailed work. More detailed information can be found from genuine
125  publications written by original authors.  publications written by original authors.
126    
# Line 127  publications written by original authors Line 128  publications written by original authors
128    
129  There are three research problems related to this thesis. First research problem  There are three research problems related to this thesis. First research problem
130  is to find the most efficient way to locate and fetch Fenfire related data from the  is to find the most efficient way to locate and fetch Fenfire related data from the
131  Peer-to-Peer network, where Scroll block's identifier is given. Second, we want  Peer-to-Peer network, where Storm scroll block's identifier is given. Second, we want
132  to find the most efficient way to locate and fetch most recent Fenfire related data from the  to find the most efficient way to locate and fetch most recent Fenfire related data from the
133  the Peer-to-Peer network, which is associated with a given urn-5 random string. Third problem  the Peer-to-Peer network, which is associated with a given pointer random string. Third problem
134  is otherwise same as the second problem, except we want to locate and fetch all Fenfire  is otherwise same as the second problem, except we want to locate and fetch all Fenfire
135  related data from the Peer-to-Peer network, where given date and/or time range is given.  related data from the Peer-to-Peer network, where given date and/or time range is given.
136    
 When comparing different Peer-to-Peer approaches and algorithms, we will examine their  
 scalability, efficiency, space requirements for neighbor connections and overhead  
 associated with system maintenance. Finally, when we have solutions to our research  
 problems, we will use best solutions as examples in our algorithm proposals.  
   
137  \section{Thesis overview}  \section{Thesis overview}
138  This thesis is structured as follows. In next chapter, we give an overview of  This thesis is structured as follows. In next chapter, we give an overview of
139  existing Peer-to-Peer approaches, algorithms and key differences. In chapter 3, we  existing Peer-to-Peer approaches, algorithms and key differences. In chapter 3, we
140  address open problems in Peer-to-Peer domain and divide problems into three  address open problems in Peer-to-Peer domain and divide problems into three
141  sub-categories. Chapter 4 gives an overview of Fenfire system. In chapter  sub-categories. Chapter 4 gives an overview of Fenfire system. In chapter
142  5, we evaluate existing Peer-to-Peer approaches with regard to Fenfire system and  5, we evaluate existing Peer-to-Peer approaches with regard to Fenfire system, propose system
143  propose simple algorithms to perform data lookups in Fenfire's Peer-to-Peer enviroment.  model for Fenfire in Peer-to-Peer environment, present simple algorithms to perform data
144  Then, we discuss open issues and future work. In chapter 6, we present conclusions.  lookups in Peer-to-Peer environment. Also, we discuss possible problems of using Fenfire
145    in Peer-to-Peer environment. In chapter 6, we present conclusions and future work.
146    
147    
148  \chapter{Peer-to-Peer architectures}  \chapter{Peer-to-Peer architectures}
# Line 182  regard to OSI model. Line 179  regard to OSI model.
179  \end{figure}  \end{figure}
180    
181  Compared to ARPANET's Peer-to-Peer functionality, today's Peer-to-Peer systems  Compared to ARPANET's Peer-to-Peer functionality, today's Peer-to-Peer systems
182  are ad-hoc, i.e. peers join and leave the system constantly in a dynamic manner. This  are ad-hoc, i.e., peers join and leave the system constantly in a dynamic manner. This
183  fact constitutes challenging requirements for efficient construction and maintenance  fact constitutes challenging requirements for efficient construction and maintenance
184  of the overlay network. Even more demanding tasks are how to perform efficient data  of the overlay network. Even more demanding tasks are how to perform efficient data
185  lookup and maintain security in a varying distributed environment. The most popular  lookup and maintain security in a varying distributed environment. The most popular
# Line 220  key differences. Line 217  key differences.
217  Napster\footnote{We decided to include Napster in this section only because it has  Napster\footnote{We decided to include Napster in this section only because it has
218  historical value (see previous section).} \cite{napsterurl}  was designed to to allow  historical value (see previous section).} \cite{napsterurl}  was designed to to allow
219  people to share music. It was a hybrid Peer-to-Peer file-sharing system, i.e., the search  people to share music. It was a hybrid Peer-to-Peer file-sharing system, i.e., the search
220  index was centralized and the distribution storage and serving of files was distributed.  index was centralized and the distribution of storage and serving of files was distributed.
221  Peers in the Napster network performed requests to the central directory server to find  Peers in the Napster network performed requests to the central directory server to find
222  other peers hosting desirable content. Since service requests was totally based on  other peers hosting desirable content. Since service requests was totally based on
223  centralized index, Napster didn't scale well because of constantly updated central  centralized index, Napster didn't scale well because of constantly updated central
# Line 246  other nodes in a random manner. Thus, gn Line 243  other nodes in a random manner. Thus, gn
243    
244    
245  In Gnutella, each participating peer maintains local index of its own shared content. Also,  In Gnutella, each participating peer maintains local index of its own shared content. Also,
246  each peer has a few connections to other peer, i.e. peer's \emph{neighbors}. Basic gnutella  each peer has a few connections to other peer, i.e., peer's \emph{neighbors}. Basic gnutella
247  data lookup works as follows: peer broadcasts a query request to its neighors, which in turn  data lookup works as follows: peer broadcasts a query request to its neighors, which in turn
248  forwards the query to their neighbors. This leads in the situation where number of messages  forwards the query to their neighbors. This leads in the situation where number of messages
249  in the network can grow with $O(n^{2})$, where $n$ is the number of participating peers in the  in the network can grow with $O(n^{2})$, where $n$ is the number of participating peers in the
250  Gnutella network. To limit the amount of network traffic, Gnutella uses Time-To-Live-limited  Gnutella network. To limit the amount of network traffic, Gnutella uses Time-To-Live-limited
251  (TTL) flooding to distributed queries. Gnutella uses a Breadt-First-Traversal (BFS) with depth limit  (TTL) flooding to distributed queries. Gnutella uses a Breadt-First-Search (BFS) with depth limit
252  $T$ (e.g., 7), where $T$ is the system-wide maximum TTL of a message in hops. Therefore, only peers that  $T$ (e.g., 7), where $T$ is the system-wide maximum TTL of a message in hops. Therefore, only peers that
253  are TTL hops away from the query originator will forward the query or respond to the query.  are TTL hops away from the query originator will forward the query or respond to the query.
254  In Gnutella network, search results are fast, because BFS sends queries to  In Gnutella network, search results are fast, because BFS sends queries to
# Line 275  significant message processing overhead Line 272  significant message processing overhead
272  the load on participating to the point, where it has to leave the network.  the load on participating to the point, where it has to leave the network.
273    
274  Lately, there has been done lot of research to improve Gnutella's data lookup efficiency  Lately, there has been done lot of research to improve Gnutella's data lookup efficiency
275  and scalability. Adamic et. all \cite{adamic99small}, \cite{adamic02localsearch},  and scalability. Adamic et al. \cite{adamic99small}, \cite{adamic02localsearch},
276  \cite{adamic01powerlawsearch} has been studied different random walk methods in power-law  \cite{adamic01powerlawsearch} has been studied different random walk methods in power-law
277  networks\footnote{In power-law networks only a few peers have high number of neighbor  networks\footnote{In power-law networks only a few peers have high number of neighbor
278  links and major of peers have low number of neighbor links.} and they have found that by  links and major of peers have low number of neighbor links.} and have found that by
279  instructing peers forwarding data lookups to select high degree peers, the performance of data lookup  instructing peers forwarding data lookups to select high degree peers, the performance of data lookup
280  increases signficantly. As a result, some of the most recent loosely  increases signficantly. As a result, some of the most recent loosely
281  structured Peer-to-Peer systems have adopted this method with some modifications  structured Peer-to-Peer systems have adopted this method with some modifications
# Line 286  structured Peer-to-Peer systems have ado Line 283  structured Peer-to-Peer systems have ado
283  \cite{kazaaurl}, \cite{jxtaurl}, \cite{jxtaoverview}, \cite{botros01jxtasearch},  \cite{kazaaurl}, \cite{jxtaurl}, \cite{jxtaoverview}, \cite{botros01jxtasearch},
284  \cite{ganesan02yappers}.  \cite{ganesan02yappers}.
285  Figures \ref{fig:gnutella_overlay_supernodes} and \ref{fig:gnutella_overlay_cluster}  Figures \ref{fig:gnutella_overlay_supernodes} and \ref{fig:gnutella_overlay_cluster}
286  illustrated two possible variations of power-law overlay networks. All the systems  illustrates two possible variations of power-law overlay networks. All the systems
287  share the property of that high degree peers maintain index of all other peers  share the property of that high degree peers maintain index of all other peers
288  they know about. However, it's not clear whether this algorithm is scalable or not,  they know about. However, it's not clear whether this algorithm is scalable or not,
289  as majority of the query request are sent only to the high degree peers, making  as majority of the query request are sent only to the high degree peers, making
# Line 309  them stress the overhead of nearly entir Line 306  them stress the overhead of nearly entir
306  Previously presented improvements are only partial solutions. Obviously, more  Previously presented improvements are only partial solutions. Obviously, more
307  research is required to make data lookup of loosely structured approach more  research is required to make data lookup of loosely structured approach more
308  scalable and effective. More advanced techniques to improve data lookup of  scalable and effective. More advanced techniques to improve data lookup of
309  loosely strcutured systems is presented in chapter 3.  loosely structured systems are presented in chapter 3.
310    
311    
312  \subsection{Sketch of formal definition}  \subsection{Sketch of formal definition}
# Line 339  Skip Graphs \cite{AspnesS2003}, SkipNet Line 336  Skip Graphs \cite{AspnesS2003}, SkipNet
336  Symphony \cite{gurmeet03symphony}, SWAN \cite{bonsma02swan}, Tapestry  Symphony \cite{gurmeet03symphony}, SWAN \cite{bonsma02swan}, Tapestry
337  \cite{zhao01tapestry}, Viceroy \cite{malkhi02viceroy} and others \cite{freedman02trie}.  \cite{zhao01tapestry}, Viceroy \cite{malkhi02viceroy} and others \cite{freedman02trie}.
338  The biggest difference compared to loosely structured approach is that with tightly structured systems,  The biggest difference compared to loosely structured approach is that with tightly structured systems,
339  it is now feasible to perform \emph{global} data lookups in overlay.  it is now feasible to perform \emph{global} data lookups in the overlay.
340  While there are significat differences among proposed systems, they all have in common  While there are significat differences among proposed systems, they all have in common
341  that participating peers are assigned \emph{peer identifiers} from  that \emph{peer identifiers} is assigned to participating peers from
342  a large \emph{identifier space}. Furthermore, application-specific  a large \emph{identifier space} by the overlay. Furthermore, application-specific
343  data items are also assigned globally unique identifiers, \emph{keys},  data items are also assigned globally unique identifiers, \emph{keys},
344  which are selected from the same identifier space. The form of identifier  which are selected from the same identifier space. The form of identifier
345  space differs between proposed systems. Circular identifier space (and variants)  space differs between proposed systems. Circular identifier space (and variants)
346  is most widely used. For instance, Chord \cite{stoica01chord}, Koorde \cite{kaashoek03koorde},  is most widely used. For instance, Chord \cite{stoica01chord}, Koorde \cite{kaashoek03koorde},
347  Pastry \cite{rowston01pastry}, SWAN \cite{bonsma02swan}, Tapestry \cite{zhao01tapestry}  Pastry \cite{rowston01pastry}, SWAN \cite{bonsma02swan}, Tapestry \cite{zhao01tapestry}
348  and Viceroy \cite{malkhi02viceroy} use a circular identifier space of $n$-bit integers modulo $2^{n}$. The  and Viceroy \cite{malkhi02viceroy} use a circular identifier space of $n$-bit integers modulo $2^{n}$. The
349  value of $n$ varies among approaches. Again, CAN \cite{ratnasamy01can} uses a $d$-dimensional cartesian  value of $n$ varies among systems. Again, CAN \cite{ratnasamy01can} uses a $d$-dimensional cartesian
350  to implement identifier space.  model to implement identifier space.
351    
352  Stoica et al.. \cite{balakrishanarticle03lookupp2p} have listed  Stoica et al.. \cite{balakrishanarticle03lookupp2p} have listed
353  four requirements for tightly structured overlays, which have to be  four requirements for tightly structured overlays, which have to be
# Line 365  To store data into tightly structured ov Line 362  To store data into tightly structured ov
362  unique key (e.g., SHA-1 \cite{fips-sha-1}) is \emph{mapped} uniformly (e.g., using consistent  unique key (e.g., SHA-1 \cite{fips-sha-1}) is \emph{mapped} uniformly (e.g., using consistent
363  hashing \cite{258660}) by the overlay to a existing peer in the overlay. Thus, tightly  hashing \cite{258660}) by the overlay to a existing peer in the overlay. Thus, tightly
364  structured overlay assigns a subset of all possible keys to every participating peer.  structured overlay assigns a subset of all possible keys to every participating peer.
365  Specifically, each peer in tightly structured overlay maintains a \emph{routing table}, which  Also, each peer in tightly structured overlay maintains a \emph{routing table}, which
366  consists of identifiers and IP addresses of other peers in the overlay. Entries of routing  consists of identifiers and IP addresses of other peers in the overlay. Entries of routing
367  table are peer's neighbors in the overlay network. Figure \ref{fig:structured_hashing} illustrates the  table are peer's neighbors in the overlay network. Figure \ref{fig:structured_hashing} illustrates the
368  process of data to key mapping in tightly strucuted overlays.  process of data to key mapping in tightly strucuted overlays.
# Line 395  Kademlia's \cite{maymounkov02kademlia} X Line 392  Kademlia's \cite{maymounkov02kademlia} X
392  stabilization (like in Chord \cite{stoica01chord}) and backup links  stabilization (like in Chord \cite{stoica01chord}) and backup links
393  (like in Pastry \cite{rowston01pastry}) \cite{balakrishanarticle03lookupp2p}.  (like in Pastry \cite{rowston01pastry}) \cite{balakrishanarticle03lookupp2p}.
394  However, in all previously schemes each  However, in all previously schemes each
395  hop in the overlay shortens the distance between current peer working with query  hop in the overlay shortens the distance between current peer working with the data lookup
396  and the key which was looked up in the identifier space.  and the key which was looked up in the identifier space.
397    
398  Skip Graphs and Swan employ a key space very similar to a tightly structured  Skip Graphs and Swan employ a key space very similar to a tightly structured
# Line 410  PeerNet differs from other tightly struc Line 407  PeerNet differs from other tightly struc
407  at the \emph{network} level layer. Peernet makes an explicit distinction  at the \emph{network} level layer. Peernet makes an explicit distinction
408  between peer identity and address, which is not supported by standard  between peer identity and address, which is not supported by standard
409  TCP/IP-protocols. Otherwise, PeerNet has the same performance properties  TCP/IP-protocols. Otherwise, PeerNet has the same performance properties
410  as other tightly structured overlays, i.e. $O(\log{n})$ space required  as other tightly structured overlays, i.e., $O(\log{n})$ space required
411  for maintaining information about other peers in the system and  for maintaining information about other peers in the system and
412  $O(\log{n})$ data lookup efficiency.  $O(\log{n})$ data lookup efficiency.
413    
# Line 422  data structure which resembles Skip list Line 419  data structure which resembles Skip list
419  In figure \ref{fig:structured_query}, we present overview of Chord's lookup process.  In figure \ref{fig:structured_query}, we present overview of Chord's lookup process.
420  On the left side of Chord's lookup process, we show the same data lookup process  On the left side of Chord's lookup process, we show the same data lookup process
421  as binary-tree abstraction.  We can notice, that in each step, the distance between  as binary-tree abstraction.  We can notice, that in each step, the distance between
 the query originator and the target in both methods is halved. Thus, the  
422  locarithmic efficiency.  locarithmic efficiency.
423    
424  Kademlia \cite{maymounkov02kademlia}, Pastry \cite{rowston01pastry} and Tapestry  Kademlia \cite{maymounkov02kademlia}, Pastry \cite{rowston01pastry} and Tapestry
# Line 470  scalable group multicast/anycast operati Line 466  scalable group multicast/anycast operati
466  The basic operations are \texttt{join(groupIdentifier)}, \texttt{leave(groupIdentifier)},  The basic operations are \texttt{join(groupIdentifier)}, \texttt{leave(groupIdentifier)},
467  \texttt{multicast(message, groupIdentifier)},  \texttt{anycast(message, groupIdentifier)}.  \texttt{multicast(message, groupIdentifier)},  \texttt{anycast(message, groupIdentifier)}.
468  Participating peers may join and leave the group and send multicast messages to  Participating peers may join and leave the group and send multicast messages to
469  the group, or anycast message to a specific member of the group. DOLR's and CAST's  the group, or anycast message to a specific member of the group. DOLR and CAST abstraction
470  have much in common.For instance, they both use network proximity techniques  have much in common. For instance, they both use network proximity techniques
471  to optimize their operation in the overlay. Figure \ref{fig:Strucutred_lookup_using_DOLR_model}  to optimize their operation in the overlay. Figure \ref{fig:Strucutred_lookup_using_DOLR_model}
472   presents basic operation of DOLR abstraction.   presents basic operation of DOLR abstraction.
473    
# Line 494  to optimize their operation in the overl Line 490  to optimize their operation in the overl
490  \subsection{Sketch of formal definition}  \subsection{Sketch of formal definition}
491    
492  In this subsection we formalize tightly strucured overlay's main features. The model  In this subsection we formalize tightly strucured overlay's main features. The model
493  describes basic features of tightly structured overlay, i.e. identifiers, identifier  describes basic features of tightly structured overlay, i.e., identifiers, identifier
494  space and mapping function.  space and mapping function.
495    
496  Let $S$ be the aggregate of all services $s$ in system. Let $P$ be the aggregate of  Let $S$ be the aggregate of all services $s$ in system. Let $P$ be the aggregate of
# Line 540  structured approach has certain features Line 536  structured approach has certain features
536  (such as mapping of data items).  (such as mapping of data items).
537    
538  To end user, biggest difference between these systems is how data lookups are performed. Loosely  To end user, biggest difference between these systems is how data lookups are performed. Loosely
539  structured systems provides much more richier and user friendly way of searching data as they  structured systems provide much more richier and user friendly way of searching data as they
540  have support for keyword search and fuzzy search. On the other hand, tightly structured systems support  have support for keyword search and fuzzy search. On the other hand, tightly structured systems support
541  only exact key lookups as each data item is identified by globally unique keys.  only exact key lookups as each data item is identified by globally unique keys.
542    
# Line 657  and their key properties with regard to Line 653  and their key properties with regard to
653  includes algorithms from two main approaches. However, majority of the algorithms  includes algorithms from two main approaches. However, majority of the algorithms
654  listed above belongs to tightly structured approach since there has been active  listed above belongs to tightly structured approach since there has been active
655  research being pursued towards tightly structured approach lately. List doesn't  research being pursued towards tightly structured approach lately. List doesn't
656  include \emph{all} proposed Peer-to-Peer systems. Only the ones which already have  include \emph{all} proposed Peer-to-Peer algorithms. Only the ones which already have
657  been widely deployed in real-life, or the ones which may promising in the future's  been widely deployed in real-life, or the ones which may promising in the future's
658  Peer-to-Peer systems, are included in this thesis.  Peer-to-Peer systems are included in this thesis.
659    
660  We decided to follow the guidelines from \cite{kaashoek03koorde} when  We decided to follow the guidelines from \cite{kaashoek03koorde} when
661  measuring properties of different Peer-to-Peer systems. However, we dropped  measuring properties of different Peer-to-Peer systems. However, we dropped
662  out fault tolerance and load balancing properties, since they are hard to measure  out fault tolerance and load balancing properties, since they are hard to measure
663  in face of real life requirements. Additionally, we decided to include  in face of real life requirements. Additionally, however, we decided to include
664  the number of \emph{real} network connections for each peer in the overlay.  the number of \emph{real} network connections for each peer in the overlay.
665    
666  Here, we describe the listed properties of Peer-to-Peer algorihms:  Here, we describe the listed properties of Peer-to-Peer algorihms:
# Line 886  Both loosely structured and tightly stru Line 882  Both loosely structured and tightly stru
882  Since Napster \cite{napsterurl} and Gnutella \cite{gnutellaurl} was first time introduced  Since Napster \cite{napsterurl} and Gnutella \cite{gnutellaurl} was first time introduced
883  to public, researchers' main concern has been scalability problem of loosely structured  to public, researchers' main concern has been scalability problem of loosely structured
884  approach. However, people often misunderstand the scalability problem of loosely structured  approach. However, people often misunderstand the scalability problem of loosely structured
885  approach; \emph{network} of loosely structured systems is scalable, but the \emph{query model} is not.  approach; \emph{network} of loosely structured systems is scalable, but the \emph{data lookup model} is not.
886  The main concern of tightly structured system is to make overlay's data lookup  The main concern of tightly structured system is to make overlay's data lookup
887  routing more flexible againts hostile attacks. Another key problem in tightly structured  routing more flexible againts hostile attacks. Another key problems in tightly structured
888  approach are the lack of keyword searches and support for heterogeneous peers.  systems are the lack of keyword searches and support for heterogeneous peers.
889    
890  To make Peer-to-Peer systems even more popular (e.g., in industry), Peer-to-Peer domain  To make Peer-to-Peer systems even more popular (e.g., in industry), Peer-to-Peer domain
891  needs better infrastructures to deal with security issues. There has been done some  needs better infrastructures to deal with security issues. There has been done some
892  research regarding anonymity, access control, data availability and data integrity. However,  research regarding anonymity, access control, data availability and data integrity but as
893  more research is needed specifically with redundancy, robustness and entity identification.  we will observe, much more research work is required to solve security related issues.
   
894    
895  \section{Security problems in Peer-to-Peer}  \section{Security problems in Peer-to-Peer}
896    
# Line 909  general Distrubuted Denial of Service at Line 904  general Distrubuted Denial of Service at
904    
905  In Sybil attack model, hostile entity presents multiple  In Sybil attack model, hostile entity presents multiple
906  entities. Therefore, one hostile entity can control a large fraction of the Peer-to-Peer system. Optimal  entities. Therefore, one hostile entity can control a large fraction of the Peer-to-Peer system. Optimal
907  possible solution to Sybil attack would be that system could \emph{distinct} entities of system reliably. Unfortunately,  possible solution to Sybil attack would be that system could \emph{distinct} entities of the system reliably. Unfortunately,
908  currently there no realizable techiques for this task. Partial solutions for Sybil is attack is to replicate  currently there no realizable techiques for this task. Partial solutions for Sybil is attack is to replicate
909  and fragment data randomly among several participating peer. However, both suggestions assume that two different  and fragment data randomly among several participating peer. However, both suggestions assume that two different
910  remote entities are actually different; Sybil attacks are still possible and therefore, would need centralized  remote entities are actually different; Sybil attacks are still possible and therefore, would need centralized
# Line 919  resource parity and coordination among e Line 914  resource parity and coordination among e
914    
915  In random fail-stop model, cited in \cite{naor03simpledht}, faulty peer is deleted from the Peer-to-Peer system.  In random fail-stop model, cited in \cite{naor03simpledht}, faulty peer is deleted from the Peer-to-Peer system.
916  The reason for faultyness of peer can be a software failure, a hostile attack, or external threat such as virus or  The reason for faultyness of peer can be a software failure, a hostile attack, or external threat such as virus or
917  troijan. Closey related to fail-stop model is the Byzantine attack model  troijan. Closely related to fail-stop model is the Byzantine attack model
918  \cite{357176}. Byzantine model can been seen more seveve than fail-stop model as there are no restrictions over  \cite{357176}. Byzantine model can been seen more seveve than fail-stop model as there are no restrictions over
919  the behaviour of faulty peers. Partial, practical solution for byzantine failures has been proposed by Castro et  the behaviour of faulty peers. Practical, but partial solution for byzantine failures has been proposed by Castro et
920  al \cite{296824}.  al \cite{296824}.
921    
922  Spam generating attack is another known attack model againts Peer-to-Peer system. In Spam  Spam generating attack is another known attack model againts Peer-to-Peer system. In Spam
923  attack, hostile or faulty peer may produce false information of the data, or refuses/is not able to reply to requests.  attack, hostile or faulty peer may produce false information of the data, or refuses/is not able to reply to requests.
924  Possible solution againts this attack is that peer should not trust to single entity. Instead peer should get  Possible solution againts this attack is that peer should not trust to single entity. Instead, peer should get
925  information from multiple entities and trust on majority's opinion. This methods requires more messages to be  information from multiple entities and trust on majority's opinion. This methods requires more messages to be
926  sent to network increasing the load of system. However, if Spam attack is combined with Sybil attack, obviously  sent to network whilce increasing the load of system. However, if Spam attack is combined with Sybil attack, obviously
927  previously mentioned solution doesn't work. Again, more research is required to solve this attack model  previously mentioned solution doesn't work. Again, more research is required to solve this attack model
928  reliability. Naor et al. \cite{naor03simpledht} has proposed a partial solution againts Spam attack with  reliability. Naor et al. \cite{naor03simpledht} has proposed a partial solution againts Spam attack with
929  \emph{faulty} peers (not hostile).  \emph{faulty} peers (not hostile).
# Line 961  systems \cite{rivest96sdsi}, \cite{spkiw Line 956  systems \cite{rivest96sdsi}, \cite{spkiw
956  data in rather \emph{static} computing systems, such as in the Internet. However, in Peer-to-Peer  data in rather \emph{static} computing systems, such as in the Internet. However, in Peer-to-Peer
957  network, the problem of key based security mechanism is the maintenance of the keys as participating  network, the problem of key based security mechanism is the maintenance of the keys as participating
958  peer constantly join and leave the system. Specifically, the distribution of key changes comes an essential  peer constantly join and leave the system. Specifically, the distribution of key changes comes an essential
959  problem in ad hoc enviroments. These include revokation of keys and new key distribution. Also, the scenario  problem in ad hoc enviroments. These include revokation of keys and new key distribution in hostile
960  in which hostile peers are present has to be addressed.  environment.
961    
962  ConChord \cite{ajmani02conchord} is the first Peer-to-Peer system which has a support for PKI based  ConChord \cite{ajmani02conchord} is the first Peer-to-Peer system which has a support for PKI based
963  security infrastructure. Unfortunately, ConChord is in early in development and lacks of important  security infrastructure. Unfortunately, ConChord is in early in development and lacks of important
# Line 978  IP address of peer can be verified by th Line 973  IP address of peer can be verified by th
973    
974  \subsection{Anonymity}  \subsection{Anonymity}
975    
976  According to \cite{dingledine00free}, there exists several kinds of anonymity. Author-anonymity is form  According to \cite{dingledine00free}, there exists several kinds of anonymity. Author-anonymity is a form
977  of anonymity in which no one can link author to a specific document. In publisher-anonymity system,  of anonymity in which no one can link author to a specific document. In publisher-anonymity system,
978  no one is able to link publisher to a specific document. Reader-anonymity means that a specific  no one is able to link publisher to a specific document. Reader-anonymity means that a specific
979  document cannot be linked to document's readers. This form of anonymity protects the privacy of a  document cannot be linked to document's readers. This form of anonymity protects the privacy of a
980  users of the system. Furthermore, in peer-anonymity means that no peer can be linked to a specific document, i.e.  users of the system. Furthermore, peer-anonymity means that no peer can be linked to a specific document, i.e.,
981  no one is able to determine the peer, where document was originally published. Document-anonymity  no one is able to determine the peer, where document was originally published. Document-anonymity
982  means that peer doesn't know which data it is currently hosting. Finally, query-anonymity refers is form  means that peer doesn't know which data it is currently hosting. Finally, query-anonymity is a form
983  of document-anonymity; when other peers performs data lookups, peer doesn't know which data it servers  of document-anonymity; when other peers performs data lookups, peer doesn't know which data it serves
984  to the data lookup originators. As the authors cite, some of forms of anonymity may imply each other and  to the data lookup originators. As the authors cite, some of forms of anonymity may imply each other and
985  possible issues are one area of future work.  possible issues are one area of future work.
986    
# Line 993  With regard to anonymity in Peer-to-Peer Line 988  With regard to anonymity in Peer-to-Peer
988  level layer \cite{tarzan:ccs9} and at application level layer \cite{reiter98crowds}, \cite{mixminionurl}.  level layer \cite{tarzan:ccs9} and at application level layer \cite{reiter98crowds}, \cite{mixminionurl}.
989  Research on anonymity outside of Peer-to-Peer context have been done also \cite{352607}, \cite{293447}.  Research on anonymity outside of Peer-to-Peer context have been done also \cite{352607}, \cite{293447}.
990    
991  Obviously, providing several types of anonymity, anonymity often conflicts with other key properties of  Obviously, providing several types of anonymity, it often conflicts with other key properties of
992  Peer-to-Peer system. Let's consider anonymity and efficient data lookup. In efficient lookup, we must know  Peer-to-Peer system. Let's consider anonymity and efficient data lookup. In efficient data lookup, we must know
993  the peers responsible to given data in Peer-to-Peer system. Of course, when we know the peers responsible  the peers responsible to given data in Peer-to-Peer system. Of course, when we know the peers responsible
994  for the data, the anonymity of peer is lost. Fortunately, there are partial solutions to previously  for the data, the anonymity of peer is lost. Fortunately, there are partial solutions to previously
995  mentioned situations, i.e. \emph{pseudonym} which is a partial form of anonymity. For instance, pseudonym can used for  mentioned situations, such as \emph{pseudonym} which is a partial form of anonymity. For instance, pseudonym can used for
996  addressing peer-anonymity by providing anonymous-like identifiers to peers (e.g., peer identifiers of tightly  addressing peer-anonymity by providing anonymous-like identifiers to peers (e.g., peer identifiers of tightly
997  structured system).  structured system).
998    
# Line 1011  sharing methods to split a data into dat Line 1006  sharing methods to split a data into dat
1006  of anonymity  of anonymity
1007    
1008  Even if many existing Peer-to-Peer systems are able to provide some of the types of anonymity, there is no  Even if many existing Peer-to-Peer systems are able to provide some of the types of anonymity, there is no
1009  such a system which is able to provide all kinds of anonymity as listed above. Furthermore, the conflicts  such a system which is able to provide all kinds of anonymity as listed above. Specifically, the conflicts
1010  between anonymity and other Peer-to-Peer system properties requires more research work.  between anonymity and other Peer-to-Peer system properties requires more research work.
1011    
1012    
1013  \subsection{Access control}  \subsection{Access control}
1014    
1015  Any distributed computing system must support different levels of access control. For instance, we may  Any distributed computing system must support different levels of access control. For instance, in Peer-to-Peer
1016  want to restrict the accessibility of data to only limited amount of participating peers. Peer-to-Peer  system, we may want to restrict the accessibility of data to only limited amount of participating peers. Yet, Peer-to-Peer
1017  systems doesn't support working and distributed access control scheme. Moreover,  systems doesn't have working and distributed access control scheme. Moreover,
1018  there has been a lot of violation of copyright laws by users of Peer-to-Peer filesharing systems. As a  there has been a lot of violation of copyright laws by users of Peer-to-Peer filesharing systems. As a
1019  consequence, some lawsuits has been created againts the companies how have build popular file-sharing programs.  consequence, some lawsuits has been created againts the companies how have build popular file-sharing programs.
1020    
# Line 1035  Possible solutions include self-monitori Line 1030  Possible solutions include self-monitori
1030  proposed in \cite{sit02securitycons}, distributed and secure peer identifier assignment  proposed in \cite{sit02securitycons}, distributed and secure peer identifier assignment
1031  \cite{castro02securerouting}, \cite{clarke00freenet} and self-certifying data using cryptographic  \cite{castro02securerouting}, \cite{clarke00freenet} and self-certifying data using cryptographic
1032  content hashes (e.g., SHA-1 \cite{fips-sha-1}). Identification of hostile entities is essential in tightly structured  content hashes (e.g., SHA-1 \cite{fips-sha-1}). Identification of hostile entities is essential in tightly structured
1033  approach, in which fundamental (and implicit) assumption is that there is random, uniform distribution  approach, in which fundamental (and implicit) assumption is that there is a random, uniform distribution
1034  of peer identifiers that cannot be controlled by hostile entity.  of peer identifiers that cannot be controlled by hostile entity.
1035    
1036  Of course centralized authorities could be used for assignment of peer identifiers, but they have  Of course centralized authorities could be used for assignment of peer identifiers, but they have
# Line 1045  for controlling the rate at which and ho Line 1040  for controlling the rate at which and ho
1040  puzzles \cite{juels99clientpuzzles}.  puzzles \cite{juels99clientpuzzles}.
1041    
1042  In the end, none of previously mentioned solutions are able to identify hostile entities in practical,  In the end, none of previously mentioned solutions are able to identify hostile entities in practical,
1043  efficient way. More research is required to solve this problems.  efficient way. More research is required to solve these problems.
1044    
1045    
1046  \subsection{Secure query routing}  \subsection{Secure query routing}
1047    
1048  Much work has been done on secure routing, especially in tightly structured systems. In  Much work has been done on secure routing, especially related to tightly structured systems. In
1049  \cite{castro02securitystructured} and \cite{castro02securerouting}, authors suggests the usage  \cite{castro02securitystructured} and \cite{castro02securerouting}, authors suggests the usage
1050  of constrained routing tables and diverse routes, and detection of faults during query routing.  of constrained routing tables and diverse routes, and detection of faults during query routing.
1051  Additionally, authors present a important aspect of tightly structured approach with regard  Additionally, authors present a important aspect of tightly structured approach with regard
# Line 1062  to observe lookup progress and cross-che Line 1057  to observe lookup progress and cross-che
1057   approach is not very efficient, since proposals create a lot of additional network traffic when   approach is not very efficient, since proposals create a lot of additional network traffic when
1058  in function.  in function.
1059    
1060  Additionally, Lynch et al.. \cite{lynch02atomicdataaccess} propose a solution to secure routing table  Additionally, Lynch et al. \cite{lynch02atomicdataaccess} propose a solution to secure routing table
1061  maintenance, but their solution seems to have to major problems \cite{castro02securitystructured}. First,  maintenance, but their solution seems to have to major problems \cite{castro02securitystructured}. First,
1062  the solution is very expensive even without faulty or hostile entities. Second, each group of replicas  the solution is very expensive even without faulty or hostile entities. Second, each group of replicas
1063  in their solution must have less than 1/3 of its peer faulty. Thus, this feature results in a low  in their solution must have less than 1/3 of its peer faulty. Thus, this feature results in a low
# Line 1071  probability of succesfull routing. Line 1066  probability of succesfull routing.
1066  Aspnes et al. in \cite{aspnes02faultrouting} and Kaashoek et al.l in \cite{kaashoek03koorde} formally  Aspnes et al. in \cite{aspnes02faultrouting} and Kaashoek et al.l in \cite{kaashoek03koorde} formally
1067  prove the lower and upper bounds for space requirements of locating a specific date item in  prove the lower and upper bounds for space requirements of locating a specific date item in
1068  Peer-to-Peer system. They show that to provide high degree of fault tolerance and efficiency, each  Peer-to-Peer system. They show that to provide high degree of fault tolerance and efficiency, each
1069  participating peer must maintain $O(\log{n})$ neighbors.  participating peer must maintain average of $O(\log{n})$ neighbors.
1070    
1071  Fiat et al. in \cite{fiat02censorship}, \cite{saia02dynamicfaultcontentnetwork} and Datar in \cite{datar02butterflies}    Fiat et al. in \cite{fiat02censorship}, \cite{saia02dynamicfaultcontentnetwork} and Datar in \cite{datar02butterflies}  
1072  describe tightly structured overlay with analytical results in the presence of hostile entities. However,  describe tightly structured overlay with analytical results in the presence of hostile entities. However,
1073  none of these proposals doesn't address an efficient, dynamic tightly structured overlay and multiple rounds  none of these proposals doesn't address an efficient, dynamic tightly structured overlay and multiple rounds
1074  of hostile attack. Also, above mentioned propsals are not very efficient. In \cite{fiat02censorship}, each node  of hostile attack. Also, above mentioned proposals are not very efficient. In \cite{fiat02censorship}, each node
1075  must maintain information of $O(\log^3{n})$ other peers, and in \cite{datar02butterflies}, $O(\log^2{n})$ is required.  must maintain information of $O(\log^3{n})$ other peers, and in \cite{datar02butterflies}, $O(\log^2{n})$ is required.
1076    
1077  Finally, Ratnasamy and Gavoille \cite{ratnasamy02routing}, \cite{gavoille01routing} list several open problems  Finally, Ratnasamy and Gavoille \cite{ratnasamy02routing}, \cite{gavoille01routing} list several open problems
1078  regarding routing in distributed networks. Obviously, more research is required in order to provde secure  regarding routing in distributed networks. Obviously, more research is required in order to provide secure
1079  data lookup routing possible in Peer-to-Peer networks.  data lookup routing possible in Peer-to-Peer networks.
1080    
1081    
1082  \subsection{Other security threats}  \subsection{Other security threats}
1083    
1084  Ross Lee graham lists several external threats againts Peer-to-Peer networks \cite{grahamp2psecurity}. The list  Ross Lee graham lists several external threats againts Peer-to-Peer networks \cite{grahamp2psecurity}. Most important, t
1085  includes viruses, trojans and bugs in Peer-to-Peer software. Currently, there are not even partial solutions  he list includes viruses and trojans. Currently, there are not even partial solutions
1086  to the problems mentioned above. General robustness properties of Peer-to-Peer system is able to  to the problems mentioned above. General robustness properties of Peer-to-Peer system is able to
1087  deal with software failures and hostile attack, but redundancy againts external threats is unknown.  deal with software failures and hostile attack, but redundancy againts external threats is unknown.
1088  The reason for this is that there are no experiences on these kinds of attacks. Possible solution  The reason for this is that there are no experiences on these kinds of attacks. Possible solution
1089  would be distributed anti-virus software, but much more intensive research is required for solve these problems.  would be distributed anti-virus software, but much more intensive research is required until
1090    this kind of solution would be applicable.
1091    
1092    
1093    
# Line 1106  The most intensive research in Peer-to-P Line 1102  The most intensive research in Peer-to-P
1102  especially with loosely structured approach. In addition to ''super-peer'' method presented in chapter  especially with loosely structured approach. In addition to ''super-peer'' method presented in chapter
1103  2, there has been other improvements also.  2, there has been other improvements also.
1104  In iterative deepening  In iterative deepening
1105  \cite{yang02improvingsearch}, multiple breadt-first searches are initiated  \cite{yang02improvingsearch}, multiple BFS searches are initiated
1106  with successively larger TTL depth limits, until either the query is satisfied,  with successively larger TTL depth limits, until either the query is satisfied,
1107  or the maximumum depth $D$ has been reached. To perform a data lookup, query  or the maximumum depth $D$ has been reached. To perform a data lookup, query
1108  originator starts a flood with small TTL value. If the search is not succesful,  originator starts a data lookup with small TTL value. If the search is not succesful,
1109  the query originator increases the TTL value and performs another flood. This  the query originator increases the TTL value and performs another data lookup. This
1110  process is repeated until the desired data is found or maximumum depth $D$  process is repeated until the desired data is found or maximumum depth $D$
1111  has been reached. Expanding ring, proposed by Shenker et al.., \cite{lv02searchreplication},  has been reached. Expanding ring, proposed by Shenker et al.., \cite{lv02searchreplication},
1112  is similar to iterative deepening techique. With these techniques, search  is similar to iterative deepening techique. With these techniques, search
# Line 1120  Directed BFS \cite{yang02improvingsearch Line 1116  Directed BFS \cite{yang02improvingsearch
1116  BFS in way that peer selects neighbors with many quality results  BFS in way that peer selects neighbors with many quality results
1117  may be reached, thereby maintaining the the quality of costs and decreasing the amount  may be reached, thereby maintaining the the quality of costs and decreasing the amount
1118  of messages sent to network. Alpine \cite{alpineurl} and NeuroGrid \cite{joseph02neurogrid}  of messages sent to network. Alpine \cite{alpineurl} and NeuroGrid \cite{joseph02neurogrid}
1119  are Peer-to-Peer system use somewhat similar method when performing data lookups.  are Peer-to-Peer system which use somewhat similar method when performing data lookups.
1120    
1121  Local indices \cite{yang02improvingsearch} is one variation of active caching.  Local indices \cite{yang02improvingsearch} is one variation of active caching.
1122  In this scheme, each peer maintains an index over the data of all nodes within  In this scheme, each peer maintains an index over the data of all nodes within
# Line 1136  has poor response time. As suggested in Line 1132  has poor response time. As suggested in
1132  random walk approach can be done more effective by introducing  random walk approach can be done more effective by introducing
1133  multiple ''walkers''. Freenet \cite{clarke00freenet} Peer-to-Peer system uses  multiple ''walkers''. Freenet \cite{clarke00freenet} Peer-to-Peer system uses
1134  random walk searches in query lookups. Indeed, Freenet's query resembles  random walk searches in query lookups. Indeed, Freenet's query resembles
1135  depth-first traversal and peers' routing tables are dynamically built  Depth-First-Search (DFS) and peers' routing tables are dynamically built
1136  using caching. This is an outcome of Freenet's main design priciples,  using caching. This is an outcome of Freenet's main design priciples,
1137  i.e., anonymity. Additional improvements to Freenet's data lookup using  i.e., anonymity. Additional improvements to Freenet's data lookup using
1138  ''small-world phenomenon'' has been proposed by Zhang et al.. \cite{zhang02using}.  ''small-world phenomenon'' has been proposed by Zhang et al.. \cite{zhang02using}.
# Line 1147  current research efforts are focused on Line 1143  current research efforts are focused on
1143  peers try to choose routing-tables entries refering to other peers that are \emph{nearby} in the  peers try to choose routing-tables entries refering to other peers that are \emph{nearby} in the
1144  underlying network. In this way, tightly structured systems are able to decrease actual  underlying network. In this way, tightly structured systems are able to decrease actual
1145  lookup \emph{latency}. CAN \cite{ratnasamy01can}, Kademlia \cite{maymounkov02kademlia},  lookup \emph{latency}. CAN \cite{ratnasamy01can}, Kademlia \cite{maymounkov02kademlia},
1146  Pastry \cite{rowston01pastry} and Tapestry \cite{zhao01tapestry} have a advanced heuristics for  Pastry \cite{rowston01pastry} and Tapestry \cite{zhao01tapestry} have advanced heuristics for
1147  proximity based routing. Additionally, most recent version of Chord uses proximity based  proximity based routing. Additionally, most recent version of Chord uses proximity based
1148  routing inspired by Karger and Ruhl \cite{karger02findingnearest}. Skipnet \cite{harvey03skipnet1}  routing inspired by Karger and Ruhl \cite{karger02findingnearest}. Skipnet \cite{harvey03skipnet1}
1149  uses combination of proximity and application level overlay routing when performing data  uses combination of proximity and application level overlay routing when performing data
# Line 1167  is the ability to perform keyword or fuz Line 1163  is the ability to perform keyword or fuz
1163  structured systems are able carry out this requirement. Unfortunately, as discussed in this text,  structured systems are able carry out this requirement. Unfortunately, as discussed in this text,
1164  the data lookup model of loosely structured approach is not scalable. Thus, research efforts have  the data lookup model of loosely structured approach is not scalable. Thus, research efforts have
1165  been focused on tightly structured approach.  been focused on tightly structured approach.
1166  The main in problem with tightly structured approach is the fact that tightly structured algorihms  The main problem with tightly structured approach is the fact that tightly structured algorihms
1167  performs data lookups based on a globally unique identifier. Quite recent study has been focused  performs data lookups based on a globally unique identifier (key). Quite recent study has been focused
1168  on the feasibility of Peer-to-Peer Web-like indexing and searching \cite{li03feasibility}. Authors  on the feasibility of Peer-to-Peer Web-like indexing and searching \cite{li03feasibility}. Authors
1169  argue, that it is possible to implement Peer-to-Peer Web-like search with certain radical compromises.  argue, that it is possible to implement Peer-to-Peer Web-like search with certain radical compromises.
1170  First, Peer-to-Peer search enginge may need to decrease result quality in order make searching more  First, Peer-to-Peer search engine may need to decrease result quality in order make searching more
1171  efficient. Second, Peer-to-Peer systems must observe better the properties of underlying network for  efficient. Second, Peer-to-Peer systems must observe better the properties of underlying network for
1172  better performance.  better performance.
1173    
1174  Some studies have been concentraded on SQL-like queries \cite{harren02complex}  Some studies have been concentrated on SQL-like queries \cite{harren02complex}
1175  in tightly structured overlays. Another approaches includes adaption of data lookup model of loosely  in tightly structured overlays. Another approaches include adaption of data lookup model of loosely
1176  structured approach into tightly structured systems \cite{ansaryefficientbroadcast03}, \cite{chord:om_p-meng}.  structured approach into tightly structured systems \cite{ansaryefficientbroadcast03}, \cite{chord:om_p-meng}.
1177  Additional studies include additional layer upon overlay network \cite{kronfol02fasdsearch},  Additional studies include additional layer upon overlay network \cite{kronfol02fasdsearch},
1178  \cite{joseph02p2players} and range queries \cite{andrzejak02rangequeries}.  \cite{joseph02p2players} and range queries \cite{andrzejak02rangequeries}.
1179    
1180  Many techniques have been developed in order to provide more efficient search indexing. As  Many techniques have been developed in order to provide more efficient search indexing. As
1181  studies queries follow Zipf-like distributions\footnote{Zipf distribution is a variant of power-law function.  several studies show, the popularity of queries in the Internet follow Zipf-like
1182    distributions\footnote{Zipf distribution is a variant of power-law function.
1183  Zipf-distribution can be used in observation of frequency of occurrence event $E$, as a function of the rank  Zipf-distribution can be used in observation of frequency of occurrence event $E$, as a function of the rank
1184  $i$ when the rank is determined by the frequency of occurrence, $E_i \sim \frac{1}{i^{a}}$, where the exponent  $i$ when the rank is determined by the frequency of occurrence, $E_i \sim \frac{1}{i^{a}}$, where the exponent
1185  $a$ is close to unity.} \cite{breslau98implications} caching and precomputation  $a$ is close to unity.} (e.g., \cite{breslau98implications}), caching and precomputation
1186  can be done for optimizting search indices \cite{li03feasibility}. Regular compression algorithms,  can be done for optimizting search indices \cite{li03feasibility}. Regular compression algorithms,
1187  Bloom filters \cite{362692}, vector space models \cite{CuencaAcuna2002DSIWorkshop} and view  Bloom filters \cite{362692}, vector space models \cite{CuencaAcuna2002DSIWorkshop} and view
1188  trees \cite{Bhattacharjee03resultcache} can be used for even better optimizations. Authors  trees \cite{Bhattacharjee03resultcache} can be used for even better optimizations. Authors
# Line 1223  minimum half-life over all times $t$. Co Line 1220  minimum half-life over all times $t$. Co
1220  more efficient analytical tools for modelling complex Peer-to-Peer system.  more efficient analytical tools for modelling complex Peer-to-Peer system.
1221    
1222  Some research has been done with regard to load balancing properties of tightly structured  Some research has been done with regard to load balancing properties of tightly structured
1223  overlays. Byers et al.. suggest "power of two choices" whereby an item is stored at the less loaded  overlays. Byers et al. suggest "power of two choices" whereby an item is stored at the less loaded
1224  of two (or more) random alternatives \cite{byers03dhtbalancing}. Rao et al.. uses virtual servers  of two (or more) random peer alternatives \cite{byers03dhtbalancing}. Rao et al. uses virtual servers
1225  to control load balance in Peer-to-Peer systems \cite{rao03loadbalancing}. Their work rests on  to control load balance in Peer-to-Peer systems \cite{rao03loadbalancing}. Their work rests on
1226  idea which was originally introduced by Chord system.  idea which was originally introduced by Chord \cite{stoica01chord} system.
1227    
1228  Also, query and routing hotspots may be an issue in tightly structured overlays \cite{ratnasamy02routing}.  Also, query and routing hotspots may be an issue in tightly structured overlays \cite{ratnasamy02routing}.
1229  Hotspots happen, when specific key is being requested extremely often in tightly structured overlays. Recent study  Hotspots happen, when specific key is being requested extremely often in tightly structured overlays. Recent study
1230  by Freedman et al.. tries to reduce hot spots in the system by performing \emph{sloppy} hashing  by Freedman et al. tries to reduce hot spots in the system by performing \emph{sloppy} hashing
1231  \cite{sloppy:iptps03}. Another key feature of their work is that peers self-organize into clusters,  \cite{sloppy:iptps03}. Another key feature of their work is that peers self-organize into clusters,
1232  therefore enabling peers to find nearby data without looking up data from distant peers.  therefore enabling peers to find nearby data without looking up data from distant peers.
1233    
1234  An implicit assumption of almost every tightly structured system is that there is random, uniform  As mentioned before, an implicit assumption of almost every tightly structured system is that there is random, uniform
1235  distribution of peer and key identifiers. Even if participating peers are extremely heterogeneous in  distribution of peer and key identifiers. Even if participating peers are extremely heterogeneous in
1236  face of computing power, or network bandwidth, data items are distributed uniformly. Clearly, this  face of computing power, or network bandwidth, data items are distributed uniformly. Clearly, this
1237  a serious problem of tightly structured overlays , since measurement study by Saroiu et al.. shows  a serious problem of tightly structured overlays in face of performance and load balancing. Measurement study
1238  that there extreme heterogeneity among participating peers in already deployed Peer-to-Peer systems.  by Saroiu et al. shows that there is extreme heterogeneity among participating peers in already deployed Peer-to-Peer
1239  \cite{saroiu02measurementstudyp2p}. Symphony seems to be the first tightly structured overlay system  systems \cite{saroiu02measurementstudyp2p}. Symphony seems to be the first tightly structured overlay system
1240  which support hetergeneity. However, Zhao et al.. have proposed a secondary layer a top of structured overlay  which support hetergeneity. Zhao et al. have proposed a secondary layer a top of structured overlay
1241  to support hetergeneity better \cite{zhao02brocade}.  to support hetergeneity better \cite{zhao02brocade}.
1242    
1243  Research has been done on self-organization. Ledlie et al.. propose techniques for forming and maintaining  Research has been done on self-organization. Ledlie et al. propose techniques for forming and maintaining
1244  groups in highly dynamic environment \cite{ledlie02selfp2p}. Unfortunately their work relies on idea that  groups in highly dynamic environment \cite{ledlie02selfp2p}. Unfortunately their work relies on idea that
1245  participating peers would create multiple hierarchical groups; it's not clear whether this approach  participating peers would create multiple hierarchical groups; it's not clear whether this approach
1246  is fault-tolerant and suitable to Peer-to-Peer environment. More promising work has been done by Rowston et al..  is fault-tolerant and suitable to Peer-to-Peer environment. More promising work has been done by Rowston et al.
1247  in \cite{rowston03controlloingreliability}. Authors propose techiques for self-tuning, dealing with  in \cite{rowston03controlloingreliability}. Authors propose techiques for self-tuning, dealing with
1248  uncommon conditions (e.g., network partition and high failure rates). Moreover, authors arque that  uncommon conditions (e.g., network partition and high failure rates). Moreover, authors arque that
1249  these techniques, the concerns over the tightly structured overlay maintenance costs are no more  with these techniques, the concerns over the tightly structured overlay maintenance costs are no more
1250  an open issue.  an open issue.
1251    
1252  Finally, little research has been done regarding self-monitoring and data availability. Zhang et al..  Finally, little research has been done regarding self-monitoring and data availability. Zhang et al.
1253  describe a arbitrary data structure on top of tightly structured overlay \cite{zhang03somo}. They  describe a arbitrary data structure on top of tightly structured overlay \cite{zhang03somo}. They
1254  call their proposal as \emph{data overlay}, since it support several fundamental data structures.  call their proposal as \emph{data overlay}, since it supports several fundamental data structures.
1255  Authors use this data overlay to build Self-Organized Metadata Overlay (SOMO), which can be used  Authors use this data overlay to build Self-Organized Metadata Overlay (SOMO), which can be used
1256  for monitoring health of tightly structured overlay. Fault tolerance of SOMO itself is currently  for monitoring health of tightly structured overlay. Fault tolerance of SOMO itself is currently
1257  unknown.  unknown.
# Line 1266  In this section we discuss miscellaneous Line 1263  In this section we discuss miscellaneous
1263    
1264  \subsection{Programming guidelines and benchmarks}  \subsection{Programming guidelines and benchmarks}
1265    
1266  All existing Peer-to-Peer systems have rather different interfaces even they common points and  All existing Peer-to-Peer systems have rather different interfaces even they have common points and
1267  components. More important, all existing Peer-to-Peer systems incompatible with each other. One  components. More important, all existing Peer-to-Peer systems incompatible with each other. One
1268  of the most important area of future research is to create common programming abstractions, i.e.  of the most important area of future research is to create common programming abstractions, i.e.,
1269  interfaces, design patters and frameworks. Also, equal benchmarks are needed for comparing  interfaces, design patters and frameworks. Also, equal benchmarks are needed for comparing
1270  different algorithms. Recently, there have been few proposals towards common programming  different algorithms. Recently, there have been few proposals towards common programming
1271  guidelines. This list includes \cite{zhao03api}, \cite{frise02p2pframework}, \cite{babaoglu02anthill}.  guidelines. This list includes \cite{zhao03api}, \cite{frise02p2pframework}, \cite{babaoglu02anthill}.
# Line 1284  and peers are unwilling to cooperate \ci Line 1281  and peers are unwilling to cooperate \ci
1281    
1282  Somewhat surprisingly little research has been in this area, especially when considering  Somewhat surprisingly little research has been in this area, especially when considering
1283  the possible impact of this \emph{unwanted socical behaviour} to performance of Peer-to-Peer  the possible impact of this \emph{unwanted socical behaviour} to performance of Peer-to-Peer
1284  system. Problem is addressed by Golle et al.. \cite{golle01incentivesp2p}. Some  system. Problem is addressed by Golle et al. \cite{golle01incentivesp2p}. Some
1285  research has been focused on semantic properties of the overlay in order to increase  research has been focused on semantic properties of the overlay in order to increase
1286  cooperation among participating peers \cite{crespo02semanticoverlay}. Ramanathan et al..  cooperation among participating peers \cite{crespo02semanticoverlay}. Ramanathan et al.
1287  \cite{ramanathan02goodpeers} and Bernstein et al.. \cite{bernstein03selection} use  \cite{ramanathan02goodpeers} and Bernstein et al. \cite{bernstein03selection} use
1288  empirical metrics and decision trees when teaching peers to make better decisions  empirical metrics and decision trees when teaching peers to make better decisions
1289  when contacting other peers in Peer-to-Peer system. Alpine \cite{alpineurl} is an example of  when contacting other peers in Peer-to-Peer system. Alpine \cite{alpineurl} is an example of
1290  Peer-to-Peer system, which uses empirical metrics for peer selection.  Peer-to-Peer system, which uses empirical metrics for peer selection.
# Line 1297  Peer-to-Peer system, which uses empirica Line 1294  Peer-to-Peer system, which uses empirica
1294    
1295  Very little research has been done on simulating the \emph{global} Peer-to-Peer system. Presumably, this  Very little research has been done on simulating the \emph{global} Peer-to-Peer system. Presumably, this
1296  is due to complex nature of Peer-to-Peer system, which makes comprehensive simulations very  is due to complex nature of Peer-to-Peer system, which makes comprehensive simulations very
1297  diffucult. Floyd et al.. has been studying the simulation of the Internet in \cite{504642}. Authors  diffucult. Floyd et al. has been studying the simulation of the Internet in \cite{504642}. Authors
1298  state that simulating the Internet is very challenging task, because of Internet's heterogeneity  state that simulating the Internet is very challenging task, because of Internet's heterogeneity
1299  and rapid change. Obviously, these factors exist also in Peer-to-Peer system even with higher  and rapid change. Obviously, these factors exist also in Peer-to-Peer system even with higher
1300  rates.  rates.
# Line 1310  Internet and in Peer-to-Peer systems. Line 1307  Internet and in Peer-to-Peer systems.
1307  \section{Summary}  \section{Summary}
1308    
1309  In this section we summarize open problems in Peer-to-Peer systems. All open problems entries  In this section we summarize open problems in Peer-to-Peer systems. All open problems entries
1310  listed in this section are not necessarily mentioned in the previous sections. This is because  listed in this section are not necessarily mentioned in the previous sections. Problems listed
1311  we discussed only the most significant problems earlier. Problems listed here are variations  here are variations of previously mentioned problems, or otherwise related to them. For each entry,
1312  of previously mentioned problems, or otherwise related to them. For each entry, there is brief  there is brief description of the problem, possible solutions and comments respectively.
 description of the problem, possible solutions and comments respectively.  
1313    
1314  Next, we list open problems in Peer-to-Peer domain. In table \ref{table_security_problems_Peer-to-Peer}  Next, we list open problems in Peer-to-Peer domain. In table \ref{table_security_problems_Peer-to-Peer}
1315  we list open problems related to security; in table \ref{table_performanceusability_problems_Peer-to-Peer},  we list open problems related to security; in table \ref{table_performanceusability_problems_Peer-to-Peer},
# Line 1648  we list miscellaneous open problems. Line 1644  we list miscellaneous open problems.
1644    
1645  \chapter{Fenfire hypermedia system}  \chapter{Fenfire hypermedia system}
1646    
1647  In this chaper we give an overview of Fenfire system. We also  In this chapter we give an overview of Fenfire system. We also
1648  describe briefly xanalogical model. At the end of this chapter we study Storm,  describe briefly xanalogical model. At the end of this chapter we study Storm,
1649  Fenfire's software module, which is an essential part of Fenfire's Peer-to-Peer  Fenfire's software module, which is an essential part of Fenfire's Peer-to-Peer
1650  functionality.  functionality.
# Line 1657  functionality. Line 1653  functionality.
1653    
1654  Fenfire project \cite{fenfireurl} is an effort to build a distributed, hyperstructured user  Fenfire project \cite{fenfireurl} is an effort to build a distributed, hyperstructured user
1655  interface system. Fenfire is free software and it is licenced under GNU L-GPL. Fenfire's main goal  interface system. Fenfire is free software and it is licenced under GNU L-GPL. Fenfire's main goal
1656  is to implement xanalogical storage model \cite{ted-xu-model}. Fenfire was formely also an implementation  is to implement xanalogical storage model \cite{ted-xu-model}. Fenfire was formely also a implementation
1657  of the ZigZag\texttrademark --structure, which was originally invented  of the ZigZag\texttrademark --structure, which was originally invented
1658  by Ted Nelson. Now, however, Fenfire uses Resource Description Framework \cite{w3rdfurl}  by Ted Nelson. Now, however, Fenfire uses Resource Description Framework (RDF) \cite{w3rdfurl}
1659  for representing internal data structures and their relationships.  for representing internal data structures and their relationships.
1660    
1661  Fenfire is high modular software system. It consists of several independent software modules:  Fenfire is high modular software system. It consists of several independent software modules:
# Line 1673  Fenfire is high modular software system. Line 1669  Fenfire is high modular software system.
1669  \item \textbf{LibVob}: graphic library used for creating navigation interfaces in complex data views  \item \textbf{LibVob}: graphic library used for creating navigation interfaces in complex data views
1670  \end{itemize}  \end{itemize}
1671    
1672  In this thesis, we focus on Storm and Xu-Storm modules, since they are the foundation of Fenfire's  In this thesis, we focus on Storm and Alph modules, since they are the foundation of Fenfire's
1673  Peer-to-Peer functionality. If not otherwise mentioned, we use term 'Storm' referring to both  Peer-to-Peer functionality. If not otherwise mentioned, we use term 'Storm' referring to both
1674  Storm and Alph modules.  Storm and Alph software modules.
1675    
1676  \section{Xanalogical model}  \section{Xanalogical model}
1677    
1678  Xanalogical storage \cite{nelson99xanalogicalneeded} is different kind of model for  Xanalogical storage \cite{nelson99xanalogicalneeded} is a different kind of model for
1679  presenting data and relationships between data. While in World Wide Web links are  presenting data and relationships between data. While in World Wide Web links are
1680  between \emph{documents}, in xanalogical model links are between individual  between \emph{documents}, in xanalogical model links are between individual
1681  \emph{characters}. Indeed, each character in xanalogical storage model has a  \emph{characters}. Indeed, each character in xanalogical storage model has a
# Line 1706  enfilade of contents already used in ano Line 1702  enfilade of contents already used in ano
1702  different data contents. By using this mechanism, system implementing xanalogical model  different data contents. By using this mechanism, system implementing xanalogical model
1703  is able to show all data content that share same fluid media with current data content  is able to show all data content that share same fluid media with current data content
1704  (e.g., all documents containing current document's text). Figure \ref{fig:xanalogical_model}  (e.g., all documents containing current document's text). Figure \ref{fig:xanalogical_model}
1705  illustrates xanalogical model used with documents, text and characters.  illustrates xanalogical storage model with documents, text and characters.
1706    
1707    
1708  \begin{figure}  \begin{figure}
# Line 1719  illustrates xanalogical model used with Line 1715  illustrates xanalogical model used with
1715    
1716  \section{Storm}  \section{Storm}
1717    
1718  In this section, we will give an brief overview of Storm design. More information can be found  In this section, we will give a brief overview of Storm design. More information can be found
1719  from recent publications: for general discussion about Fenfire in Peer-to-Peer environment,  from recent publications: for general discussion about Fenfire in Peer-to-Peer environment,
1720  see \cite{lukka02freenetguids}, and for detailed Storm design, see \cite{fallenstein03storm}.  see \cite{lukka02freenetguids}, and for detailed Storm design, see \cite{fallenstein03storm}.
1721    
1722  Storm (for \emph{STORage Module}) is a software module, which is used in Fenfire for  Storm (for \emph{STORage Module}) is a software module, which is used in Fenfire for
1723  implementing basic data storage operations. Storm stores all data as \emph{blocks}, which  data storage operations. Storm stores all data as \emph{blocks}, which
1724  are immutable byte sequences. SHA-1\footnote{SHA-1 is considered a collision free  are immutable byte sequences. SHA-1\footnote{SHA-1 is considered a collision free
1725  hash function. Therefore, it is very unlikely that two different Storm data blocks  hash function. Therefore, it is very unlikely that two different Storm data blocks
1726  would have same identifier.} cryptographic content hash \cite{fips-sha-1} is used  would have same identifier.} cryptographic content hash \cite{fips-sha-1} is used
1727  for creating locatiotion-independent, globally unique identifiers for blocks. Additionally,  for creating locatiotion-independent, globally unique identifiers for blocks. Additionally,
1728  SHA-1 \cite{fips-sha-1} is used for verifying the integrity of scroll blocks. Storm  SHA-1 \cite{fips-sha-1} is used for verifying the integrity of Storm data blocks. Storm
1729  blocks have much in common with regular files, except Storm blocks are \emph{immutable} as  blocks have much in common with regular files, except Storm blocks are \emph{immutable} as
1730  any change to the byte sequence would the change block's hash value, i.e., unique  any change to the byte sequence would the change block's hash value, i.e., unique
1731  identifier. This mechanism creates a basis for implementing xanalogical model in our  identifier. This mechanism creates a basis for implementing xanalogical model in
1732  Fenfire system. Figure \ref{fig:storm_model} illustrated simplified Storm storage model.  Fenfire system. Figure \ref{fig:storm_model} illustrates simplified Storm storage model.
1733    
1734  \begin{figure}  \begin{figure}
1735  \centering  \centering
# Line 1748  In addition to immutable data, Storm has Line 1744  In addition to immutable data, Storm has
1744  we discuss only pointers as they are part of the thesis' research problems.  we discuss only pointers as they are part of the thesis' research problems.
1745  More information about diffs can be found from \cite{fallenstein03storm}.  More information about diffs can be found from \cite{fallenstein03storm}.
1746    
1747  Pointer is a updatable reference to scroll block. In practice, pointer is a  Pointer \cite{benja02urn5} is an updatable reference to Storm data block, i.e., Storm scroll block.
1748  random string created automatically by Storm \cite{benja02urn5}, associated  In practice, pointer is a random string created automatically by Storm ,
1749  with a collection of \emph{pointer blocks}. Each pointer block has a single  associated with a collection of \emph{pointer blocks}. Each pointer block has a single
1750  target for the pointer. In figure \ref{fig:storm_model}, we present overal  target for the pointer. In figure \ref{fig:storm_model}, we present overal
1751  pointer creation process. Pointer block may contain zero or more obsoleted  pointer creation process. Pointer block may contain zero or more obsoleted
1752  pointer blocks, i.e. when a new version of scroll block is created, it supersedes  pointer blocks, i.e. when a new version of scroll block is created, it supersedes
# Line 1771  the most recent pointer's block target i Line 1767  the most recent pointer's block target i
1767    
1768  In this chapter we evaluate Fenfire in Peer-to-Peer environment.  In this chapter we evaluate Fenfire in Peer-to-Peer environment.
1769  We start by giving a problem overview when considering Fenfire in Peer-to-Peer  We start by giving a problem overview when considering Fenfire in Peer-to-Peer
1770  environment. Then, we define Fenfire's objectives and special needs in Peer-to-Peer  environment. We define Fenfire's special needs and evaluate existing
1771  environment. Finally, we evaluate different peer-to-peer approaches with regard  Peer-to-Peer approaches in light of these requirements. After that, we propose system
1772  to Fenfire, and propose initial algorihms for obtaining Fenfire specific data  model for Fenfire in Peer-to-Peer environment, present simple algorithms to perform data
1773  from Peer-to-Peer overlay network.    lookups in Peer-to-Peer environment. Also, we discuss possible problems of using Fenfire
1774    in Peer-to-Peer environment
1775    
1776    
1777  \section{Problem overview}  \section{Problem overview}
# Line 1810  Some research regarding to these problem Line 1807  Some research regarding to these problem
1807  \cite{lukka02freenetguids}. Authors' work is mainly based on insight of implementing  \cite{lukka02freenetguids}. Authors' work is mainly based on insight of implementing
1808  xanalogical model in Peer-to-Peer enviroment with globally unique identifiers. Lukka et al.  xanalogical model in Peer-to-Peer enviroment with globally unique identifiers. Lukka et al.
1809  use Freenet \cite{clarke00freenet} as a example Peer-to-Peer system supporting  use Freenet \cite{clarke00freenet} as a example Peer-to-Peer system supporting
1810  globally unique identifiers. This thesis presented here extends their work by  globally unique identifiers. The work presented in this thesis extends their work by
1811  evaluating different Peer-to-Peer approaches more extensively to Fenfire's needs.  evaluating different Peer-to-Peer systems more extensively to Fenfire's needs.
1812    
1813  Additionally, related to non-xanalogical hypermedia systems, Bouving  Additionally, related to non-xanalogical hypermedia systems, Bouving
1814  \cite{bouvin02openhypermedia} has done initial work regarding  ways in which  \cite{bouvin02openhypermedia} has done initial work regarding  ways in which
# Line 1833  in the overlay, whereas the data lookup Line 1830  in the overlay, whereas the data lookup
1830  is limited to certain area of overlay\footnote{The area depends on where the query  is limited to certain area of overlay\footnote{The area depends on where the query
1831  originator is located in the overlay.}.  originator is located in the overlay.}.
1832    
1833  For Fenfire's special needs for \emph{locating} data, the most important advantage of  For Fenfire's special needs for \emph{locating} data, an important advantage of
1834  tightly structured approach over loosely structured approach is that tightly  tightly structured approach over loosely structured approach is that tightly
1835  structured systems use location-independent, globally unique identifiers for  structured systems use location-independent, globally unique identifiers for
1836  identifying data in the system. Indeed, this  identifying data in the system. Indeed, this
# Line 1843  to provide general purpose \emph{interfa Line 1840  to provide general purpose \emph{interfa
1840  Currently, Domain Name System (DNS) \cite{rfc1101} is widely used RRS system in the Internet.}  Currently, Domain Name System (DNS) \cite{rfc1101} is widely used RRS system in the Internet.}
1841   \cite{balakrishnan03semanticfree}. Authors argue that next generation RRS must be   \cite{balakrishnan03semanticfree}. Authors argue that next generation RRS must be
1842  application-independent and references itself should be \emph{unstructured} and  application-independent and references itself should be \emph{unstructured} and
1843  \emph{semantic free}. To summarize, these aspects may be the most important features  \emph{semantic free}. Finally, with tightly stuctured systems, it is feasible to
1844    perform \emph{global} data lookups in the overlay. To summarize, these aspects may be the most important features
1845  of Peer-to-Peer infrastructure with regard to Fenfire as a \emph{distributed} hypermedia system.  of Peer-to-Peer infrastructure with regard to Fenfire as a \emph{distributed} hypermedia system.
1846  Thus, we see the tightly structured approach the best alternative to locate data in Peer-to-Peer  Thus, we see the tightly structured approach the best alternative to locate data in Peer-to-Peer
1847  environment.  environment.
# Line 1910  on rateless erasure codes \cite{maymounk Line 1908  on rateless erasure codes \cite{maymounk
1908    
1909  \subsection{Algorithms}  \subsection{Algorithms}
1910    
1911  We use DOLR model of tightly of structured approach, i.e. each participating peer hosts  We use DOLR abstraction of tightly of structured approach, i.e. each participating peer hosts
1912  the data and overlay maintains only the \emph{pointers} to the data. We descided to use DOLR in our  the data and overlay maintains only the \emph{pointers} to the data. We descided to use DOLR in our
1913  model, since DOLR systems locate date without specifiying a storage policy explicity \cite{rhea03benchmarks}.  model, since DOLR systems locate date without specifiying a storage policy explicity \cite{rhea03benchmarks}.
1914  DHT based storage systems, such as CFS \cite{dabek01widearea} and PAST \cite{rowstron01storage}, have  DHT based storage systems, such as CFS \cite{dabek01widearea} and PAST \cite{rowstron01storage}, may have
1915  critical problems with load balancing in highly heterogeneous environment. This problem is caused by peers  critical problems with load balancing in highly heterogeneous environment. This problem is caused by peers
1916  which may not able to store relative great amount of data with key/value pair, assigned randomly by  which may not able to store relative great amount of data with key/value pair, assigned randomly by
1917  mapping function of the overlay. Additionally, these systems wastes both storage and bandwidth, and  mapping function of the overlay. Additionally, these systems wastes both storage and bandwidth, and
1918  are sensitive to certain attacks (e.g., DDoS attack).  are sensitive to certain attacks (e.g., DDoS attack).
1919    
1920  In the following subsections we assume that we know the structure of  In the following subsections we assume that we know the structure of
1921  ''virtual file'' before hand, i.e. when assmbling a ''virtual file'', we know all Storm  ''virtual file'' before hand, i.e., when assembling a ''virtual file'', we know all Storm
1922  scroll/pointer blocks, which are required when building the ''virtual file''. Also, we don't  scroll/pointer blocks, which are required when building the ''virtual file''. Also, we don't
1923  respond to security issues related to Peer-to-Peer systems, since there is no working solution  respond to security issues related to Peer-to-Peer systems, since there is no working solution
1924  available yet; we either assume that Fenfire has a reliable techique for identifying invidual entities, or  available yet; we either assume that Fenfire has a reliable techique for identifying invidual entities, or
# Line 1931  key/value-pairs which peer maintains; da Line 1929  key/value-pairs which peer maintains; da
1929  chronological order (the most recent block is topmost) which peer maintains. We use Storm blocks' identifiers  chronological order (the most recent block is topmost) which peer maintains. We use Storm blocks' identifiers
1930  as \emph{keys} of the overlay. Every key/value-pairs consists of either a hash of pointer random string  as \emph{keys} of the overlay. Every key/value-pairs consists of either a hash of pointer random string
1931  (pointer blocks), or a hash of block's content (scroll blocks) as a key. Value is always a reference to a hosting  (pointer blocks), or a hash of block's content (scroll blocks) as a key. Value is always a reference to a hosting
1932  peer (e.g. IP address). We use Kademlia's \cite{maymounkov02kademlia} algorihm for locating data in the overlay.  peer (e.g. IP address). We use Kademlia's \cite{maymounkov02kademlia} algorithm for locating data in the overlay.
1933  Finally, we assume that all local operations can be done in a constant time.  Finally, we assume that all local operations can be done in a constant time.
1934    
1935    
# Line 1939  Finally, we assume that all local operat Line 1937  Finally, we assume that all local operat
1937  \item Data lookup with a given identifier of Storm scroll block.  \item Data lookup with a given identifier of Storm scroll block.
1938  \begin{enumerate}  \begin{enumerate}
1939  \item Submit query using scroll block's identifier.  \item Submit query using scroll block's identifier.
1940  \item Repeat until hosting node is found: each peer forwards the query to a closer peer which hosts the given scroll block identifier.  \item Repeat until hosting peer is found: each peer forwards the query to a closer peer which hosts the given scroll block identifier.
1941  \item Pointer peer returns most recent pointer block's value (e.g., hosting peer's IP-address) to query originator.  \item Pointer peer returns most recent pointer block's value (e.g., hosting peer's IP-address) to query originator.
1942  \item Query originator requests hosting node to return the scroll block.  \item Query originator requests hosting peer to return the scroll block.
1943  \end{enumerate}  \end{enumerate}
1944  \end{itemize}  \end{itemize}
1945    
# Line 1953  block is known. Line 1951  block is known.
1951  \begin{itemize}  \begin{itemize}
1952  \item Data lookup with a given pointer random string returning most recent scroll block.  \item Data lookup with a given pointer random string returning most recent scroll block.
1953  \begin{enumerate}  \begin{enumerate}
1954  \item Query originator locally compute a hash for given urn-5 random string.  \item Query originator locally compute a hash for given pointer random string.
1955  \item Repeat until hosting node is found: each peer forwards the query to a closer peer which hosts the given hash of pointer random string.  \item Repeat until hosting peer is found: each peer forwards the query to a closer peer which hosts the given hash of pointer random string.
1956  \item Pointer peer returns most recent pointer block's key/value-pair (e.g., hosting peer's IP-address) to query originator, using pointer block's own indexing schemes.  \item Pointer peer returns most recent pointer block's key/value-pair (e.g., hosting peer's IP-address) to query originator, using pointer block's own indexing schemes.
1957  \item Query originator requests hosting node to return the scroll block.  \item Query originator requests hosting peer to return the scroll block.
1958  \end{enumerate}  \end{enumerate}
1959  \end{itemize}  \end{itemize}
1960    
# Line 1964  block is known. Line 1962  block is known.
1962  \item Data lookup with a given pointer random string returning scroll block(s) for a given date and time range.  \item Data lookup with a given pointer random string returning scroll block(s) for a given date and time range.
1963  \begin{enumerate}  \begin{enumerate}
1964    
1965  \item Query originator locally compute a hash for given urn-5 random string.  \item Query originator locally compute a hash for given pointer random string.
1966  \item Repeat until hosting node is found: each peer forwards the query to a closer peer which hosts the given hash of pointer random string.  \item Repeat until hosting peer is found: each peer forwards the query to a closer peer which hosts the given hash of pointer random string.
1967  \item Pointer peer returns pointer block's key/value-pair(s) (e.g., hosting peer's IP-addresses) to query originator, using pointer block's own indexing schemes.  \item Pointer peer returns pointer block's key/value-pair(s) (e.g., hosting peer's IP-addresses) to query originator, using pointer block's own indexing schemes.
1968  \item Query originator requests hosting node to return the scroll block.  \item Query originator requests hosting peer to return the scroll block.
1969  \end{enumerate}  \end{enumerate}
1970  \end{itemize}  \end{itemize}
1971    
1972  Figure \ref{fig:storm_query_urn5} illustrates how Storm scroll block is located  Figure \ref{fig:storm_query_urn5} illustrates how Storm scroll block is located
1973  in a tightly structured overlay using DOLR method, where urn-5 is known.  in a tightly structured overlay using DOLR method, where pointer random string is known.
1974    
1975  Each of these algortihms can locate Fenfire related data in $\Theta(\log{n})$ time:  Each of these algortihms can locate Fenfire related data in $\Theta(\log{n})$ time:
1976  $O(\log{n})$ time for query routing to pointer peer and constant time for  $O(\log{n})$ time for query routing to pointer peer and constant time for
# Line 1983  the data is not included. Line 1981  the data is not included.
1981  \begin{figure}  \begin{figure}
1982  \centering  \centering
1983  \includegraphics[width=11cm, height=8cm]{storm_query_blockid.eps}  \includegraphics[width=11cm, height=8cm]{storm_query_blockid.eps}
1984  \caption{Locating owner peer for a given block ID}  \caption{Locating owner peer for a given Storm block identifier}
1985  \label{fig:storm_query_blockid}  \label{fig:storm_query_blockid}
1986  \end{figure}  \end{figure}
1987    
1988  \begin{figure}  \begin{figure}
1989  \centering  \centering
1990  \includegraphics[width=11cm, height=8cm]{storm_query_urn5.eps}  \includegraphics[width=11cm, height=8cm]{storm_query_urn5.eps}
1991  \caption{Locating owner peer for a given urn-5}  \caption{Locating owner peer for a given pointer random string}
1992  \label{fig:storm_query_urn5}  \label{fig:storm_query_urn5}
1993  \end{figure}  \end{figure}
1994    
# Line 1998  the data is not included. Line 1996  the data is not included.
1996  \subsection{Problems}  \subsection{Problems}
1997    
1998  Perhaps the most biggest issue in Peer-to-Peer systems is non-maturity of  Perhaps the most biggest issue in Peer-to-Peer systems is non-maturity of
1999  secure techologies. For instance online entities cannot be identified  secure techologies. For instance, online entities cannot be identified
2000  safely (e.g., the Sybil attack \cite{douceur02sybil}). For Fenfire, one  safely (e.g., the Sybil attack \cite{douceur02sybil}). For Fenfire, one
2001  security related problem occurs when user wants to perform global data lookup with a given  security related problem occurs when user wants to perform global data lookup with a given
2002  pointer random string; how user is able to verify the correctness  pointer random string; how user is able to verify the correctness
2003  of the search results, and how do we know which one is the  of the search results, and how do we know which one is the
2004  correct Storm scroll block ? Spam attack is variation of previously  correct Storm scroll block ? Spam attack \cite{naor03simpledht} is a variation of previously
2005  mentioned problem; data lookup is performed by a user, but there is no reply  mentioned problem; data lookup is performed by a user, but there is no reply
2006  from the system. How do we are able to know if this was a spam attack, or the  from the system. How do we are able to know if this was a spam attack, or the
2007  data really no exist in the system ? Another problem related to Fenfire's  data really no exist in the system ? Another problem related to Fenfire's
# Line 2012  and after network disconnetcion, user wa Line 2010  and after network disconnetcion, user wa
2010  authenticity of data. Obviously, optimal solution to all security issues would  authenticity of data. Obviously, optimal solution to all security issues would
2011  be that digital signatures are included to every message sent in the system.  be that digital signatures are included to every message sent in the system.
2012  However, these problems are not only limited to Fenfire, it concerns all  However, these problems are not only limited to Fenfire, it concerns all
2013  Peer-to-Peer based computer systems. We believe these problem is solved in a  Peer-to-Peer based computer systems.
 near future as very intesive research is carried out in Peer-to-Peer field.  
2014    
2015  \chapter{Conclusions and future work}  \chapter{Conclusions and future work}
2016    
2017  In this thesis, we have reviewed existing Peer-to-Peer approaches, algorithms and  In this thesis, we have reviewed existing Peer-to-Peer approaches, algorithms and
2018  their properties. Currently, two main Peer-to-Peer overlay approaches  their properties. Currently, two main Peer-to-Peer overlay approaches
2019  exist: loosely and tightly structured ovelrays. We discussed approaches'  exist: loosely and tightly structured overlays. We have discussed differences,
2020  differences, disadvantages and advantages.  disadvantages and advantages of both approaches.
2021    
2022  After that, we summarized open problems in Peer-to-Peer networks. Specifically,  After that, we summarized open problems in Peer-to-Peer networks. Specifically,
2023  we divided open problems into three sub-categories: security related problems,  we divided open problems into three sub-categories: security related problems,
# Line 2030  yet, or solutions are only partial. Much Line 2027  yet, or solutions are only partial. Much
2027  solve open problems.  solve open problems.
2028    
2029  Then, we focused our attention to Fenfire system. First, we gave a brief  Then, we focused our attention to Fenfire system. First, we gave a brief
2030  overview of Fenfire and xanalogical model. We also discussed Storm and urn-5,  overview of Fenfire and xanalogical model. We also described Storm,
2031  which are essential parts of Fenfire's Peer-to-Peer functionality.  which is an essential part of Fenfire's Peer-to-Peer functionality.
2032    
2033  In last chapter, we evaluated existing Peer-to-Peer approaches with regard  In last chapter, we evaluated existing Peer-to-Peer approaches with regard
2034  to Fenfire's needs. We proposed, that tightly structured approach is the  to Fenfire's needs. We proposed, that tightly structured approach is the
2035  best alternative to our needs. First, Storm, xanalogical  best alternative to our needs for the following reasons. First, Storm, xanalogical
2036  model and tightly structured approach all use global unique identifiers  model and tightly structured systems use global unique identifiers
2037  for identifying data. Second, our Storm design uses Semantic-Free references  for identifying data. Second, our Storm design uses semantic-free references
2038  for locating data in distributed networks. As the authors of \cite{balakrishnan03semanticfree},  for locating data in distributed networks. As the authors of \cite{balakrishnan03semanticfree},
2039  we also observe that tightly structured overlays provide general purpose  we also observe that tightly structured overlays provide general purpose
2040  interface to next-generation reference resolution services. Second, by using  interface to next-generation reference resolution services. Second, by using
2041  DOLR method of tightly structured overlay, we can minimize the the lack  DOLR abstraction of tightly structured overlay, we can minimize the the lack
2042  of locality in tightly structured overlays. Finally, we believe that issues  of locality in tightly structured overlays. Finally, we believe that issues
2043  related to tightly structured overlays are solved in near future, because of  related to tightly structured overlays are solved in near future, because of
2044  wide and intensive co-operation among research groups.  wide and intensive co-operation among research groups.

Legend:
Removed from v.1.124  
changed lines
  Added in v.1.125

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