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 |
|
|
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 |
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 |
|
|
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} |
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 |
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 |
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 |
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 |
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 |
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} |
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 |
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. |
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 |
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 |
|
|
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 |
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 |
|
|
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 |
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 |
|
|
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: |
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 |
|
|
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 |
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). |
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 |
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 |
|
|
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 |
|
|
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 |
|
|
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 |
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 |
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 |
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 |
|
|
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 |
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 |
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}. |
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 |
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 |
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. |
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}. |
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. |
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. |
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}, |
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. |
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: |
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 |
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} |
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 |
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 |
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} |
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 |
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 |
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. |
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 |
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 |
|
|
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 |
|
|
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 |
|
|
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 |
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 |
|
|
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 |
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, |
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. |