/[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.108 by hemppah, Tue Mar 4 11:05:58 2003 UTC revision 1.109 by hemppah, Tue Mar 4 11:56:30 2003 UTC
# Line 39  sähköposti: hemppah@cc.jyu.fi} Line 39  sähköposti: hemppah@cc.jyu.fi}
39    
40    
41  \abstract{  \abstract{
42  In this thesis, we review existing Peer-to-Peer approaches, protocols and their  In this thesis, we review existing Peer-to-Peer approaches, algorithms and their
43  key properties. We summarize open problems in Peer-to-Peer networks and divide  key properties. We summarize open problems in Peer-to-Peer networks and divide
44  problems into three sub-categories. We observe that there are many  problems into three sub-categories. We observe that there are many
45  problems, which have not solutions at all, or problems have proposed  problems, which have not solutions at all, or problems have proposed
# Line 104  and centralized infracstructure. Line 104  and centralized infracstructure.
104  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
105  data lookup and security. In this thesis, we\footnote{Use of the plural is customary even if research paper is authored solely.}  data lookup and security. In this thesis, we\footnote{Use of the plural is customary even if research paper is authored solely.}
106  focus on these aspects in Peer-to-Peer domain.  focus on these aspects in Peer-to-Peer domain.
107  Specifically, we review existing Peer-to-Peer approaches, protocols and their properties. We observe  Specifically, we review existing Peer-to-Peer approaches, algorithms and their properties. We observe
108  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
109  loosely structured approach or tightly structured approach. Then, we discuss open problems in  loosely structured approach or tightly structured approach. Then, we discuss open problems in
110  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,
# Line 120  i.e., globally unique identifiers. Final Line 120  i.e., globally unique identifiers. Final
120  algortihms to be used  with our Fenfire system in Peer-to-Peer environment.  algortihms to be used  with our Fenfire system in 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 protocols and open problems in Peer-to-Peer domain. However, this  existing Peer-to-Peer 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 134  the Peer-to-Peer network, which is assoc Line 134  the Peer-to-Peer network, which is assoc
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    
137  When comparing different Peer-to-Peer approaches and protocols, we will examine their  When comparing different Peer-to-Peer approaches and algorithms, we will examine their
138  scalability, efficiency, space requirements for neighbor connections and overhead  scalability, efficiency, space requirements for neighbor connections and overhead
139  associated with system maintenance. When we have solutions to our research  associated with system maintenance. When we have solutions to our research
140  problems, we will use best solutions as examples in our algorithm proposals.  problems, we will use best solutions as examples in our algorithm proposals.
141    
142  \section{Thesis overview}  \section{Thesis overview}
143  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
144  existing Peer-to-Peer approaches, protocols and key differences. In chapter 3, we  existing Peer-to-Peer approaches, algorithms and key differences. In chapter 3, we
145  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
146  sub-categories. Chapter 4 gives an overview of our Fenfire system. In chapter  sub-categories. Chapter 4 gives an overview of our Fenfire system. In chapter
147  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 and
# Line 151  We also discuss open issues and future w Line 151  We also discuss open issues and future w
151    
152  \chapter{Peer-to-Peer architectures}  \chapter{Peer-to-Peer architectures}
153  In this chapter we give brief history and overview of Peer-to-Peer networks,  In this chapter we give brief history and overview of Peer-to-Peer networks,
154  review most important Peer-to-Peer protocols and list key differences between  review most important Peer-to-Peer algorithms and list key differences between
155  two main approaches.  two main approaches.
156    
157  \section{Overview}  \section{Overview}
# Line 336  Koorde \cite{kaashoek03koorde}, ODHDHT \ Line 336  Koorde \cite{kaashoek03koorde}, ODHDHT \
336  Pastry \cite{rowston01pastry}, Peernet \cite{eriksson03peernet},  Pastry \cite{rowston01pastry}, Peernet \cite{eriksson03peernet},
337  Skip Graphs \cite{AspnesS2003}, SkipNet \cite{harvey03skipnet2},  Skip Graphs \cite{AspnesS2003}, SkipNet \cite{harvey03skipnet2},
338  Symphony \cite{gurmeet03symphony}, SWAN \cite{bonsma02swan}, Tapestry  Symphony \cite{gurmeet03symphony}, SWAN \cite{bonsma02swan}, Tapestry
339  \cite{zhao01tapestry} and Viceroy \cite{malkhi02viceroy}. While there  \cite{zhao01tapestry}, Viceroy \cite{malkhi02viceroy} and others \cite{freedman02trie}.
340  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 participating peers are assigned \emph{peer identifiers} from
342  a large \emph{identifier space}. Furthermore, application-specific  a large \emph{identifier space}. Furthermore, application-specific
343  data items are also assigned globally unique identifiers, \emph{keys},  data items are also assigned globally unique identifiers, \emph{keys},
# Line 349  value of $n$ varies among approaches. Ag Line 349  value of $n$ varies among approaches. Ag
349  to implement identifier space.  to implement identifier space.
350    
351  To store data into tightly structured overlay, each application-specific  To store data into tightly structured overlay, each application-specific
352  unique key (e.g., SHA-1 \cite{fips-sha-1}) is \emph{mapped} by the overlay to a  unique key (e.g., SHA-1 \cite{fips-sha-1}) is \emph{mapped} uniformly (e.g., using consistent
353  existing peer in the overlay. Thus, tightly structured overlay assigns a subset of all  hashing \cite{258660}) by the overlay to a existing peer in the overlay. Thus, tightly
354  possible keys to every participating peer. Furtermore, each peer in the structured  structured overlay assigns a subset of all possible keys to every participating peer.
355  overlay maintains a \emph{routing table}, which consists of identifiers and IP addresses  Furtermore, each peer in the structured overlay maintains a \emph{routing table}, which
356  of other peers in the overlay. These are peer's neighbors in the overlay network.  consists of identifiers and IP addresses of other peers in the overlay. These are peer's
357  Figure \ref{fig:structured_hashing} illustrates the process of data to key mapping in tightly strucuted overlays.  neighbors in the overlay network. Figure \ref{fig:structured_hashing} illustrates the
358    process of data to key mapping in tightly strucuted overlays.
359    
360  \begin{figure}  \begin{figure}
361  \centering  \centering
# Line 381  custody of a storing peer\footnote{Stori Line 382  custody of a storing peer\footnote{Stori
382  assigned keys.} keys is removed at the cost of each peer maintaining one  assigned keys.} keys is removed at the cost of each peer maintaining one
383  ''resource node'' in the overlay network for each resource item pair it publishes.  ''resource node'' in the overlay network for each resource item pair it publishes.
384    
385    PeerNet differs from other tightly structured overlays in that it operates
386    at the \emph{network} level layer. Peernet makes an explicit distinction
387    between peer identity and address, which is supported by standard
388    TCP/IP-algorithms. Otherwise, PeerNet has same performance properties
389    as other tightly structured overlays, i.e. $O(\log{n})$ space required
390    for maintaining information about other peers in the system and
391    $O(\log{n})$ data lookup efficieny.
392    
393  Stoica et al. \cite{balakrishanarticle03lookupp2p} have listed  Stoica et al. \cite{balakrishanarticle03lookupp2p} have listed
394  four requirements for tightly structured overlays, which have to be  four requirements for tightly structured overlays, which have to be
395  addressed in order to perform data lookups in tightly structured overlays.  addressed in order to perform data lookups in tightly structured overlays.
# Line 392  must be constructed and maintained adapt Line 401  must be constructed and maintained adapt
401    
402  Currently, all proposed tightly structured overlays provide at least  Currently, all proposed tightly structured overlays provide at least
403  poly--logaritmical data lookup operations. However, there are some key  poly--logaritmical data lookup operations. However, there are some key
404  differences in routing algoritms. For example, Chord, Skip graphs and  differences in the data structure that they use as a routing table. For example, Chord, Skip graphs and
405  Skipnet maintain a local data structure which resembles skip lists \cite{78977}.  Skipnet maintain a local data structure which resembles skip lists \cite{78977}.
406  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.
407  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
# Line 400  as binary-tree abstraction.  We can noti Line 409  as binary-tree abstraction.  We can noti
409  the query originator and the target in both methods is halved. Thus, the  the query originator and the target in both methods is halved. Thus, the
410  locarithmic efficiency.  locarithmic efficiency.
411    
412  Kademlia, Pastry and Tapestry uses balanced tree-like  Kademlia, Pastry and Tapestry uses balanced $k$-trees  
413  data structures. Figure \ref{fig:kademlia_lookup} shows the process of Kademlia  as routing table's data structure. Figure \ref{fig:kademlia_lookup} shows the process of Kademlia
414  data lookup. Viceroy maintains a butterfly data structure (see e.g., \cite{226658}),  data lookup. Viceroy maintains a butterfly data structure (see e.g., \cite{226658}),
415  which requires only constant number of neighbor peers while providing $O(\log{n})$ data lookup  which requires only constant number of neighbor peers while providing $O(\log{n})$ data lookup
416  efficiency. Koorde, recent modification of Chord, uses de Bruijn graphs to maintain  efficiency. Koorde, recent modification of Chord, uses de Bruijn graphs to maintain
# Line 623  approach and tightly structured approach Line 632  approach and tightly structured approach
632    
633  \subsection{Algorithms}  \subsection{Algorithms}
634    
635  Table \ref{table_Peer-to-Peer_protocols} lists proposed Peer-to-Peer algorithms  Table \ref{table_Peer-to-Peer_algorithms} lists proposed Peer-to-Peer algorithms
636  and their key properties with regard to performance and scalability. List  and their key properties with regard to performance and scalability. List
637  includes algorithms from two main approaches. However, majority of the algorithms  includes algorithms from two main approaches. However, majority of the algorithms
638  listed above belongs to tightly structured approach since there has been active  listed above belongs to tightly structured approach since there has been active
# Line 662  Here, we describe the listed properties Line 671  Here, we describe the listed properties
671  \multicolumn{6}{c}%  \multicolumn{6}{c}%
672  {{\tablename\ \thetable{} -- continued from previous page}} \\  {{\tablename\ \thetable{} -- continued from previous page}} \\
673  \hline  \hline
674  \multicolumn{1}{|c|}{\textbf{Protocol}} &  \multicolumn{1}{|c|}{\textbf{Algorithm}} &
675  \multicolumn{1}{c|}{\textbf{Insert/Delete}} &  \multicolumn{1}{c|}{\textbf{Insert/Delete}} &
676  \multicolumn{1}{c|}{\textbf{Space}} &  \multicolumn{1}{c|}{\textbf{Space}} &
677  \multicolumn{1}{c|}{\textbf{Lookup}} &  \multicolumn{1}{c|}{\textbf{Lookup}} &
# Line 730  Here, we describe the listed properties Line 739  Here, we describe the listed properties
739  \parbox{37pt}{$O(1)$ or $O(\log{n})$} &  \parbox{37pt}{$O(1)$ or $O(\log{n})$} &
740  \parbox{37pt}{$O(\log{n})$ or $O(\frac{\log{n}}{\log{}\log{n}})$} &  \parbox{37pt}{$O(\log{n})$ or $O(\frac{\log{n}}{\log{}\log{n}})$} &
741  \parbox{85pt}{$2(\log{n})$} &  \parbox{85pt}{$2(\log{n})$} &
742  \parbox{85pt}{Based on Chord protocol, uses de Bruijn graphs for better efficiency/fault-tolerance}  \parbox{85pt}{Based on Chord algorithm, uses de Bruijn graphs for better efficiency/fault-tolerance}
743  \\ \hline  \\ \hline
744    
745  \parbox{37pt}{ODHDHT \cite{naor03simpledht}} &  \parbox{37pt}{ODHDHT \cite{naor03simpledht}} &
# Line 825  Here, we describe the listed properties Line 834  Here, we describe the listed properties
834  \\ \hline  \\ \hline
835    
836    
837  \caption{Different Peer-to-Peer lookup protocols. In this table $n$ is the number of peers in the system.}  \caption{Different Peer-to-Peer lookup algorithms. In this table $n$ is the number of peers in the system.}
838  \label{table_Peer-to-Peer_protocols}  \label{table_Peer-to-Peer_algorithms}
839    
840    
841  \end{longtable}  \end{longtable}
842  \normalsize  \normalsize
843    
844      
 -service is data block, node/peer is a physical computer  
 -*servers* self-organize towards a lookup network  
 -DHTs can be thought as a 'structured overlay random graphs'  
 -There is a explicit metric space in every DHT. Term 'closeness' differs between existing DHTs: it can be XOR/numerical/eucklidean difference between identifiers  
 -Resource can *be* a resource, or a *pointer* to a resource  
 -a service request is routed towards service based on node's local knowledge  
 -identifiers are expected to be distributed uniformly  
 -DHTs require a knowledge of identifier space's size initially  
 -resembles a balanced tree structure  
 SWAN and Skip Graphs  
 -in this scheme, node = service  
 -*key-value pairs* self-organise towards a lookup network  
 -There is a explicit metric space. Term 'closeness' differs between existing DHTs: it can be XOR/numerical/eucklidean difference between identifiers  
 -Resource can *be* a resource, or a *pointer* to a resource  
 -a service request is routed towards service based on node's local knowledge  
 -services can be hosted locally (opposite to DHTs)  
 -identifiers are expected to be distributed uniformly  
 -system does find the service, if it exists  
   
   
 +fast routing (aka searching)  
 %+scalable (10^9 users, 10^14 data items)  
 +robust  
 +little network traffic  
 -own resources are mapped into the network (not necessary!!)  
 -keyword/fuzzy search not possible yet  
 -routing/query hotspots  
 -ASSUME THAT ALL NODES HAVE IDENTICAL CABABILITIES! However, in real life, p2p enviroment is extremely heterogeneous!  
   
 -the basic idea behind many DHTs is the fact that they perform operations in a binary-like tree  
 -more space/node --> the search arity is higher --> k is higher in k-ary trees  
 -DHTs' performance efficiency is derived from these tree based operations (e.g. split to half the previous scope)  
   
 Skip graphs  
 +fast routing (aka searching)  
 +scalable  
 +little network traffic (however, more than DHTs)  
 +support *data* locality, opposite to DHTs where data is spread out evenly, destroying locality. In skip graphs, hashing is not requires, only *keys* matters (which we already have)  
 +support for partial repair mechanism/self-stabilization (DHTs lack of repair mechanism/self-stabilization)  
 +the most robust algorithm up to date, tolerance of adversial faults (DHTs support only of random faults)  
 +adaptive: doesn't need to know keyspace size before hand, instead of many DHTs, which require a priori knowledge about the size of the system or its keyspace  
 +support for range queries, e.g. natural for version control: 'find latest news from yesterday', 'find largest key < news:12/12/2002', 'find all related objects nearby'  
 (in DHTs this is a open problem)  
 +There are not hotspots in skip graphs (query/routing hotsports)  
 -not network/geographical locality  
 -for our purposes, Skip Graps could be used (sensible) only for block IDs, not for URNs: in Skip Graps, there have to be total order for data elements --> for URNs, there cannot be a total order  
 -for range queries, we would have to use local sensitive hashing, *if* we want fetch blocks like 'next block = i + 1'. SHA-1 is a (secure) random hash of content (it won't help for us in this case)  
   
 Peernet  
 -Peernet is a p2p based *network layer* for large networks  
 -Peernet makes an explicit distinction between node identity and address  
 -requires no manual configuration (plug-and-play)  
 -can support wireless or wireline infrastructure  
 -log(n) routing table, log(n) search    
   
 \cite{aspnes02faultrouting}  
 \cite{ratnasamy02ght}  
 \cite{236713}  
 \cite{258660}  
   
 \cite{freedman02trie}  
   
 \cite{plaxton97accessingnearby}  
   
   
   
   
 \cite{78977}  
   
   
   
   
   
   
 \cite{garciamolina03sil}  
   
 \cite{rowston03controlloingreliability}  
   
   
   
 \cite{byers03dhtbalancing}  
   
 \cite{pias03lighthouse}  
   
   
 \cite{debruijn46graph}  
   
   
   
 \cite{Gribble:2000:SDD}  
   
   
   
 \cite{harrisoncircle}  
   
   
   
 -CFS splits files into blocks (<50Kb), PAST distributed whole files  
   
   
   
845    
846  \chapter{Open Problems in Peer-to-Peer}  \chapter{Open Problems in Peer-to-Peer}
847    
# Line 1161  to the problems mentioned above. Line 1069  to the problems mentioned above.
1069    
1070  \section{Performance and usability problems in Peer-to-Peer}  \section{Performance and usability problems in Peer-to-Peer}
1071    
1072  In this section we review open problems regarding performance and usability.  In this section, we discuss performance related issues regardin Peer-to-Peer systems.
   
 1) Which one is more important: short path length or overhead associated with keeping routing tables updated, e.g. number of state updates whenever join/leave occurs  
  (number of neighbors)  
 2) Are we able to achieve reasonably pathlenghts with less neigbors (Viceroy) ?  
 3) How big is the difference between optimal path length and worst case path length ?  
 4) How difficult is to recover from total routing mislead and the cost of it ?  
 5) Can we choose better neighbors by using network latencies instead of closeness of IDs in the ID space ? What are the effects doing so ?  
 6) Can we choose IDs (globally) based on the geographical location/distance ? Is there a working model for doing so ?  
 7) How do we should work with node heterogeneity; how big changes have to be made to existing algorithms for better support to heterogeneity ?  
   
 Principles on scalable search in decentralized, and unstructured networks \cite{lv02searchreplication}:  
 1) system must support adaptive termination  
 2) message duplication should be minimized  
 3) each additional step during search should not significantly increase the number of nodes visited  
   
 Network proximity:  
 -\cite{pias03lighthouse}, \cite{ng02predicting}  
   
   
1073    
1074  \subsection{Efficient data lookup}  \subsection{Efficient data lookup}
1075    
# Line 1220  multiple ''walkers''. Freenet \cite{clar Line 1109  multiple ''walkers''. Freenet \cite{clar
1109  random walk searches in query lookups. Indeed, Freenet's query resembles  random walk searches in query lookups. Indeed, Freenet's query resembles
1110  depth-first traversal and peers' routing tables are dynamically built  depth-first traversal and peers' routing tables are dynamically built
1111  using caching. This is an outcome of Freenet's main design priciples,  using caching. This is an outcome of Freenet's main design priciples,
1112  i.e., anonymity.  i.e., anonymity. Additional improvements to Freenet's data lookup using
1113    ''small-world phenomenon'' has been proposed by Zhang et al. \cite{zhang02using}.
1114    
1115    
1116  Since tightly structured systems have efficient data lookup at the application level overlay,  Since tightly structured systems have efficient data lookup at the application level overlay,
1117  current research efforts are focused on proximity based data lookup. In proximity based data lookup,  current research efforts are focused on proximity based data lookup. In proximity based data lookup,
1118  peers try to choose routing-tables refering to other peers that are \emph{nearby} in  peers try to choose routing-tables refering to other peers that are \emph{nearby} in the
1119  the underlying network. In this way, tightly structured systems are able to  underlying network. In this way, tightly structured systems are able to decrease actual
1120  decrease actual lookup \emph{latency}. CAN, Kademlia, Pastry and Tapestry have a advanced  lookup \emph{latency}. CAN, Kademlia, Pastry and Tapestry have a advanced heuristics for
1121  heuristics for proximity based routing. Additionally, most recent version of Chord uses  proximity based routing. Additionally, most recent version of Chord uses proximity based
1122  proximity based routing inspired by Karger and Ruhl \cite{karger02findingnearest}. Skipnet  routing inspired by Karger and Ruhl \cite{karger02findingnearest}. Skipnet \cite{harvey03skipnet1}
1123  \cite{harvey03skipnet1} uses combination of proximity and application level overlay routing  uses combination of proximity and application level overlay routing when performing data
1124  when performing data lookups. Authors call this feature \emph{constrained load balancing}.  lookups. Authors call this feature \emph{constrained load balancing}.
1125    
1126  Research related to proximity based routing include \cite{karger02findingnearest},  Research related to proximity based routing include \cite{karger02findingnearest},
1127  \cite{hildrum02distributedobject}, \cite{brinkmann02compactplacement}, \cite{rhea02probabilistic},  \cite{hildrum02distributedobject}, \cite{brinkmann02compactplacement}, \cite{rhea02probabilistic},
# Line 1238  Research related to proximity based rout Line 1129  Research related to proximity based rout
1129  more research is required to make latency heuristic more effective and practical.  more research is required to make latency heuristic more effective and practical.
1130    
1131    
 \cite{ripeanu02mappinggnutella}  
   
   
   
   
   
   
   
   
   
   
 Locality \cite{keleher-02-p2p}  
   
   
   
1132  \subsection{Fast and usable search}  \subsection{Fast and usable search}
1133    
1134  To make Peer-to-Peer systems usable in a large, these systems have to support flexible, efficient  To make Peer-to-Peer systems usable in a large, these systems have to support flexible, efficient
# Line 1287  While it is expected that web-like searc Line 1163  While it is expected that web-like searc
1163  more research is required to make indexing and searching more efficient.  more research is required to make indexing and searching more efficient.
1164    
1165    
 Improve Freenet performance with small worlds \cite{zhang02using}  
   
1166  \subsection{System management}  \subsection{System management}
1167    
1168  Adaptive system management and self-organization are essential properties  Adaptive system management and self-organization are essential properties
# Line 1399  queries follow the Zipf-like distributio Line 1273  queries follow the Zipf-like distributio
1273    
1274  \section{Summary}  \section{Summary}
1275    
1276  \cite{daswani03openproblems}  In this section we summarize open problems in Peer-to-Peer systems. All open problems entries
1277    listed in this section are not necessarily mentioned in the previous sections. This is because
1278  \cite{sit02securitycons}  we discussed only the most significant problems earlier. Problems listed here are variations
1279    of previously mentioned problems, or otherwise related to them.
 Main problems in different approaches (own conclusions, based on research efforts):  
 1) Decentralized, but structured  
 -make routing/system more flexible againts adversial attacks  
         -e.g. -there is a single point of routing failure in these approaches (h hops, little amount f of system are adversial)  
 -make searching/query model more flexible (keyword searching)  
         -use keywords/range searches instead of exact keys  
         -proposal for range searches: Scalable, Efficient Range Queries for Grid Information Services \cite{andrzejak02rangequeries}  
         -proposal for broadcast operation in DHT-based systems \cite{ansaryefficientbroadcast03} (insight: k-ary tree is a spanning tree, traverse spanning tree)  
         -proposal for complex queries in DHTs \cite{harren02complex} (insight: use SQL-like mechanisms)  
   
 2) Decentralized, but unstructured  
 -make routing more scalable: reach more nodes, create less traffic  
 -remember mention: when people talk about Gnutella's scalability issues  
 they jumble apples and oranges: *Gnutella* itself is scalable, but query model  
 is not scalable, since searching creates a lot of traffic!  
   
 3) Centralized  
 -no recent research efforts/no interests  
 -not suitable for real p2p, as Napster case showed  
   
 Current research with regard to p2p security:  
 -lot of done has been done on persistence  
 -little has been done on distinctness (sybil attack)  
 -computational puzzles for preventing DDOS attacks (force attacker perform more work than victim)  
 -puzzles can be used for accountability (Dingeline, in Peer-to-Peer: Harnessing...), but can dangerous  
 -some research has been done on on-line identities for humans. However, they often has a direct relation to phychical world  
   
   
 5.3. General security issues related to decentralized, but structured strategies  
   
 Secure routing requires \cite{castro02securerouting}:  
 1) a secure assignment of node identifiers  
 2) secure routing table maintenance  
 3) secure message forwarding  
   
 General security considerations \cite{sit02securitycons}  
 1) Define verifiable system invariants (and verify them!)  
 2) Allow querier to observe lookup progress  
 3) Assign keys to nodes in a verifiable way  
 4) Server selection in routing may be abused  
 5) Cross-check routing tables using random queries  
 6) Avoid single points of respinsability  
   
 -security summary:  
         -problem: attacker denies service, attacker return incorrect data and attacker denies data exists:  
         -solution: redundancy (replication, caching)  
         -problem: sybil attack (attacker creates multiple identities and foils the redundancy)  
         -solution: need a way to control creation of node IDs (ID = SHA-1(ip-address), challange node verify its ID)  
1280    
1281    
1282    
# Line 1670  General security considerations \cite{si Line 1496  General security considerations \cite{si
1496    
1497  \parbox{90pt}{System in flux \cite{libennowell01observations}, \cite{571863}, \cite{ledlie02selfp2p}, \cite{albert-02-statistical}} &  \parbox{90pt}{System in flux \cite{libennowell01observations}, \cite{571863}, \cite{ledlie02selfp2p}, \cite{albert-02-statistical}} &
1498  \parbox{110pt}{Nodes join and leave system constantly. What about load balancing and performance ?} &  \parbox{110pt}{Nodes join and leave system constantly. What about load balancing and performance ?} &
1499  \parbox{110pt}{Half-life phenomenon (for analysis), simple overlay maintenance and construction protocol} &  \parbox{110pt}{Half-life phenomenon (for analysis), simple overlay maintenance and construction algorithm} &
1500  \parbox{110pt}{Initial theoretical analysis have been created, but not comprehensive model for analysing different system states and its variations (e.g. complex usage patterns)}  \parbox{110pt}{Initial theoretical analysis have been created, but not comprehensive model for analysing different system states and its variations (e.g. complex usage patterns)}
1501  \\ \hline  \\ \hline
1502    
# Line 1682  General security considerations \cite{si Line 1508  General security considerations \cite{si
1508    
1509  \parbox{90pt}{Fail Stop} &  \parbox{90pt}{Fail Stop} &
1510  \parbox{110pt}{A faulty node stops working} &  \parbox{110pt}{A faulty node stops working} &
1511  \parbox{110pt}{Failure detectors, informing protocols} &  \parbox{110pt}{Failure detectors, informing algorithms} &
1512  \parbox{110pt}{Creates more network traffics, node's information can be outdated, failure detectors not reliable}  \parbox{110pt}{Creates more network traffics, node's information can be outdated, failure detectors not reliable}
1513  \\ \hline  \\ \hline
1514    
1515    
1516  \parbox{90pt}{Byzantine faults \cite{296824}} &  \parbox{90pt}{Byzantine faults \cite{296824}} &
1517  \parbox{110pt}{Faulty nodes may behave arbitrarily} &  \parbox{110pt}{Faulty nodes may behave arbitrarily} &
1518  \parbox{110pt}{Byzantine replication protocols -> get information from multiple entities, trust majority's opinion} &  \parbox{110pt}{Byzantine replication algorithms -> get information from multiple entities, trust majority's opinion} &
1519  \parbox{110pt}{Much research has been done on this field, practical solutions, decreases system's, performance slighly}  \parbox{110pt}{Much research has been done on this field, practical solutions, decreases system's, performance slighly}
1520  \\ \hline  \\ \hline
1521    
# Line 1779  General security considerations \cite{si Line 1605  General security considerations \cite{si
1605  \normalsize  \normalsize
1606    
1607    
   
   
1608  \chapter{Fenfire hypermedia system}  \chapter{Fenfire hypermedia system}
1609    
1610  In this chaper we give an overview of Fenfire system and its objectives. We also  In this chaper we give an overview of Fenfire system and its objectives. We also
# Line 2100  loosely structured overlays' good suppor Line 1924  loosely structured overlays' good suppor
1924  For the previous mentioned reasons, we see tightly structured approach the  For the previous mentioned reasons, we see tightly structured approach the
1925  better alternative to our needs. Both Storm and tightly structured overlays uses  better alternative to our needs. Both Storm and tightly structured overlays uses
1926  globally unique identifiers for locating data. Furthermore, tightly structured  globally unique identifiers for locating data. Furthermore, tightly structured
1927  overlays provides guaranteed data lookup and has very efficient lookup protocols,  overlays provides guaranteed data lookup and has very efficient lookup algorithms,
1928  which are essential to xanalogical model to be usable in distributed environment.  which are essential to xanalogical model to be usable in distributed environment.
1929  Table \ref{table_comparison_approach} lists the key feature of both approaches.  Table \ref{table_comparison_approach} lists the key feature of both approaches.
1930    
# Line 2308  is required how to implement this sensib Line 2132  is required how to implement this sensib
2132    
2133  \chapter{Conclusions}  \chapter{Conclusions}
2134    
2135  In this thesis, we have reviewed existing Peer-to-Peer approaches, protocols and  In this thesis, we have reviewed existing Peer-to-Peer approaches, algorithms and
2136  their properties. Currently, two main Peer-to-Peer overlay approaches  their properties. Currently, two main Peer-to-Peer overlay approaches
2137  exist: loosely and tightly structured ovelrays. We discussed approaches'  exist: loosely and tightly structured ovelrays. We discussed approaches'
2138  differences, disadvantages and advantages.  differences, disadvantages and advantages.

Legend:
Removed from v.1.108  
changed lines
  Added in v.1.109

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