19 |
%*********************** |
%*********************** |
20 |
\title{Fenfire in Peer-to-Peer Environment} |
\title{Fenfire in Peer-to-Peer Environment} |
21 |
|
|
22 |
\translatedtitle{Fenfire vertaisverkko ympäristössä} |
\translatedtitle{Fenfire ja vertaisverkot} |
23 |
|
|
24 |
\author{Hermanni Hyytiälä} |
\author{Hermanni Hyytiälä} |
25 |
|
|
45 |
problems, which have not solutions at all, or problems have proposed |
problems, which have not solutions at all, or problems have proposed |
46 |
solutions but they are practically unrealizable. |
solutions but they are practically unrealizable. |
47 |
|
|
48 |
Then, we give an overview of our Fenfire system. We evaluate existing |
Then, we give an overview of Fenfire system. We evaluate existing |
49 |
Peer-to-Peer approaches-- loosely and tightly structured overlays-- with regard |
Peer-to-Peer approaches-- loosely and tightly structured overlays-- with regard |
50 |
to Fenfire's needs. Finally, we propose simple algorithms to efficiently find Fenfire |
to Fenfire's needs. Finally, we propose simple algorithms to efficiently find Fenfire |
51 |
related data from Peer-to-Peer network. |
related data from Peer-to-Peer network. |
52 |
} |
} |
53 |
\tiivistelma{ |
\tiivistelma{ |
54 |
Tässä opinnäytetyössä arvioimme olemassaolevia vertaisverkkoja, protokollia ja |
Tässä opinnäytetyössä arvioimme olemassaolevia vertaisverkkoja, algoritmeja ja |
55 |
niiden erityisominaisuuksia. Teemme yhteenvedon olemassa olevista ongelmista |
niiden erityisominaisuuksia. Teemme yhteenvedon olemassa olevista ongelmista |
56 |
vertaisverkoissa ja jaamme ongelmat kolmeen alakategoriaan. Havaitsemme, että |
vertaisverkoissa ja jaamme ongelmat kolmeen alakategoriaan. Havaitsemme, että |
57 |
on olemassa useita ongelmia, joihin ei ole ratkaisua lainkaan, tai on ehdotelma |
on olemassa useita ongelmia, joihin ei ole ratkaisua lainkaan, tai on ehdotelma |
87 |
and reliability againts certain kinds of faults (e.g., single point of failure). |
and reliability againts certain kinds of faults (e.g., single point of failure). |
88 |
|
|
89 |
There are many definitions of Peer-to-Peer networks. The Intel Peer-to-Peer |
There are many definitions of Peer-to-Peer networks. The Intel Peer-to-Peer |
90 |
Working Group defines it as ''the sharing of computer resources and defines |
Working Group defines it as ''the sharing of computer resources and services |
91 |
and services by direct exchange between systems'' \cite{p2pworkinggroup}. |
by direct exchange between systems'' \cite{p2pworkinggroup}. |
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 |
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. We also 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 systems 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 hypermedia system, which implements xanalogical storage model. We |
Next, we give an overview of Fenfire hypermedia system, which implements xanalogical storage model. We |
114 |
also describe briefly Storm software module of Fenfire system, 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 Fenfire, xanalogical model and |
choose the best alternative to Fenfire's 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 system model for Fenfire in Peer-to-Peer |
i.e., globally unique identifiers. Finally, we propose system model for Fenfire in Peer-to-Peer |
119 |
environment and present yet simple but efficient algortihms to be used for data lookups in |
environment and present yet simple but efficient algortihms to be used for data lookups in |
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, propose system |
5, we evaluate existing Peer-to-Peer approaches with regard to Fenfire system, propose system |
143 |
model for Fenfire in Peer-to-Peer environment, present simple algorithms to perform data |
model for Fenfire in Peer-to-Peer environment and present simple algorithms to perform data |
144 |
lookups in Peer-to-Peer environment. Also, we discuss possible problems of using Fenfire |
lookups in Peer-to-Peer environment. In addition, we discuss possible problems of using Fenfire |
145 |
in Peer-to-Peer environment. In chapter 6, we present conclusions and future work. |
in Peer-to-Peer environment. In chapter 6, we present conclusions and future work. |
146 |
|
|
147 |
|
|
178 |
\label{fig:application_level} |
\label{fig:application_level} |
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, modern 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 |
192 |
other research areas than computer science. There has been done research regarding |
other research areas than computer science. There has been done research regarding |
193 |
to ad-hoc nature of complex networks \cite{albert-02-statistical}, \cite{albert-00-tolerance}, \cite{watts00dynamics}. |
to ad-hoc nature of complex networks \cite{albert-02-statistical}, \cite{albert-00-tolerance}, \cite{watts00dynamics}. |
194 |
It's interesting to realize that chemical properties of cells, the Internet, ad-hoc |
It's interesting to realize that chemical properties of cells, the Internet, ad-hoc |
195 |
Peer-to-Peer networks, have all in common that they self-organize based on same |
Peer-to-Peer systems, have all in common that they self-organize based on same |
196 |
principles. Furthermore, the assocation between social connections among people |
principles. Furthermore, the assocation between social connections among people |
197 |
and Peer-to-Peer overlay topology has been studied recently \cite{watts00dynamics}, |
and Peer-to-Peer overlay topology has been studied recently \cite{watts00dynamics}, |
198 |
\cite{kleinberg99small}, \cite{nips02-Kleinberg}. This insight is motivated |
\cite{kleinberg99small}, \cite{nips02-Kleinberg}. This insight is motivated |
226 |
|
|
227 |
\section{Loosely structured} |
\section{Loosely structured} |
228 |
|
|
229 |
Gnutella \cite{gnutellaurl} is well-known example of loosely structured overlay network. As in |
Gnutella \cite{gnutellaurl} is a well-known example of loosely structured overlay network. As in |
230 |
other Peer-to-Peer networks, no peer is more important than any other peer in the network. |
other Peer-to-Peer networks, no peer is more important than any other peer in the network. |
231 |
The construction and maintenance of Gnutella network is extremely ad-hoc, since participating |
The construction and maintenance of Gnutella network is extremely ad-hoc, since participating |
232 |
peers can form the overlay network based on \emph{local} knowledge. Figure \ref{fig:gnutella_overlay} |
peers can form the overlay network based on \emph{local} knowledge. Figure \ref{fig:gnutella_overlay} |
318 |
all peers $p$ in system. Then, $\forall s \in S$, there is a provider of the service, |
all peers $p$ in system. Then, $\forall s \in S$, there is a provider of the service, |
319 |
expressed as $p = provider(s)$. Every $p$ has neighbor(s), named as $neighbor$, which |
expressed as $p = provider(s)$. Every $p$ has neighbor(s), named as $neighbor$, which |
320 |
is $P$ = \{$p \in P: \exists neighbor$, which is randomly chosen from $P$\}. |
is $P$ = \{$p \in P: \exists neighbor$, which is randomly chosen from $P$\}. |
321 |
Super peer is a peer, which hosts the indices of other peers, $sp = summaryindex(provider(s))$. |
\emph{Super peer} is a peer, which hosts the indices of other peers, $sp = summaryindex(provider(s))$. |
322 |
Moreover, $\forall$ reqular peer $p$, there is super peer, which has has a index of regular |
Moreover, $\forall$ reqular peer $p$, there is super peer, which has has a index of regular |
323 |
peer's content, specifically $ps$, $P$ = \{$p \in P: \exists ps$, |
peer's content, specifically $ps$, $P$ = \{$p \in P: \exists ps$, |
324 |
where $ps$ = $summaryindex(provider(s)) \wedge (p = provider(s))$\} |
where $ps$ = $summaryindex(provider(s)) \wedge (p = provider(s))$\} |
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 circular identifier space of $n$-bit integers modulo $2^{n}$. The |
349 |
value of $n$ varies among systems. 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 |
model to implement identifier space. |
model to implement identifier space. |
351 |
|
|
|
Stoica et al.. \cite{balakrishanarticle03lookupp2p} have listed |
|
|
four requirements for tightly structured overlays, which have to be |
|
|
addressed in order to perform data lookups in tightly structured overlays. |
|
|
First, mapping of keys to peers must be done in a load-balanced |
|
|
way. Second, the overlay must be able to forward a lookup for a |
|
|
specific key to an approriate peer. Third, overlay must have a |
|
|
support for a distance function. Finally, routing tables for each peer |
|
|
must be constructed and maintained adaptively. |
|
|
|
|
352 |
To store data into tightly structured overlay, each application-specific |
To store data into tightly structured overlay, each application-specific |
353 |
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 |
354 |
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 |
402 |
for maintaining information about other peers in the system and |
for maintaining information about other peers in the system and |
403 |
$O(\log{n})$ data lookup efficiency. |
$O(\log{n})$ data lookup efficiency. |
404 |
|
|
405 |
|
Stoica et al. \cite{balakrishanarticle03lookupp2p} have listed |
406 |
|
four requirements for tightly structured overlays, which have to be |
407 |
|
addressed in order to perform efficient data lookups in tightly structured overlays. |
408 |
|
First, mapping of keys to peers must be done in a load-balanced |
409 |
|
way. Second, the overlay must be able to forward a lookup for a |
410 |
|
specific key to an approriate peer. Third, overlay must have a |
411 |
|
support for a distance function. Finally, routing tables for each peer |
412 |
|
must be constructed and maintained adaptively. |
413 |
|
|
414 |
Currently, all proposed tightly structured overlays provide at least |
Currently, all proposed tightly structured overlays provide at least |
415 |
poly--logaritmical data lookup operations. However, there are some key |
poly--logaritmical data lookup operations. However, there are some key |
416 |
differences in the data structure that they use as a routing table. For example, Chord |
differences in the data structure that they use as a routing table. For example, Chord |
502 |
function is defined as $map: I \longmapsto IS$, and coordinate point as |
function is defined as $map: I \longmapsto IS$, and coordinate point as |
503 |
$ip = map(identifier(s))$, which maps data items, expressed by a identifier to coordinate |
$ip = map(identifier(s))$, which maps data items, expressed by a identifier to coordinate |
504 |
point $ip$ in $(IS,d)$. Peer's p resources are mapped onto a set $IS$ = \{$ip \in IS: |
point $ip$ in $(IS,d)$. Peer's p resources are mapped onto a set $IS$ = \{$ip \in IS: |
505 |
\exists s \in S$, $ip = map(identifier(s)) \wedge (provider(s) = p)$\}., |
\exists s \in S$, $ip = map(identifier(s)) \wedge (provider(s) = p)$\}. |
|
which means that resources which peer provides into the system are not kept locally. |
|
506 |
Every $p$ has neighbor(s), named as $neighbor$, which are $P$ = \{$p \in P: \exists neighbor$, |
Every $p$ has neighbor(s), named as $neighbor$, which are $P$ = \{$p \in P: \exists neighbor$, |
507 |
where $difference(p,p_neighbor)= ''close''$, where $''close''$ is small difference $d$ in $(IS,d)$\}. |
where $difference(p,p_neighbor)= ''close''$, where $''close''$ is small difference $d$ in $(IS,d)$\}. |
508 |
|
|
649 |
|
|
650 |
Table \ref{table_Peer-to-Peer_algorithms} lists proposed Peer-to-Peer algorithms |
Table \ref{table_Peer-to-Peer_algorithms} lists proposed Peer-to-Peer algorithms |
651 |
and their key properties with regard to performance and scalability. List |
and their key properties with regard to performance and scalability. List |
652 |
includes algorithms from two main approaches. However, majority of the algorithms |
includes algorithms from both loosely and tightly structured approaches. However, majority of the algorithms |
653 |
listed above belongs to tightly structured approach since there has been active |
listed above belongs to tightly structured approach since there has been active |
654 |
research being pursued towards tightly structured approach lately. List doesn't |
research being pursued towards tightly structured approach lately. List doesn't |
655 |
include \emph{all} proposed Peer-to-Peer algorithms. Only the ones which already have |
include \emph{all} proposed Peer-to-Peer algorithms. Only the ones which already have |
656 |
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 |
657 |
Peer-to-Peer systems are included in this thesis. |
Peer-to-Peer systems are included in this thesis. |
658 |
|
|
659 |
We decided to follow the guidelines from \cite{kaashoek03koorde} when |
We decided to follow the guidelines from \cite{kaashoek03koorde} when |
662 |
in face of real life requirements. Additionally, however, we decided to include |
in face of real life requirements. Additionally, however, we decided to include |
663 |
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. |
664 |
|
|
665 |
Here, we describe the listed properties of Peer-to-Peer algorihms: |
Here, we describe the listed properties of Peer-to-Peer algorithms: |
666 |
|
|
667 |
\begin{itemize} |
\begin{itemize} |
668 |
\item \textbf{Lookup}: Number of messages required when a data lookup is performed |
\item \textbf{Lookup}: number of messages required when a data lookup is performed |
669 |
\item \textbf{Space}: Number of neighbors which peers knows about (neighbors) |
\item \textbf{Space}: number of neighbors which peers knows about (neighbors) |
670 |
\item \textbf{Insert/delete}: Number of messages required when a peer joins or leaves the network |
\item \textbf{Insert/delete}: number of messages required when a peer joins or leaves the network |
671 |
\item \textbf{Number of network connections}: Number of concurrent network connections required to maintain correct neighbor information |
\item \textbf{Number of network connections}: number of concurrent network connections required to maintain correct neighbor information |
672 |
\end{itemize} |
\end{itemize} |
673 |
|
|
674 |
\scriptsize |
\scriptsize |
872 |
\section{Overview} |
\section{Overview} |
873 |
|
|
874 |
Partly due to the non-maturity of modern Peer-to-Peer technology, it has several |
Partly due to the non-maturity of modern Peer-to-Peer technology, it has several |
875 |
open problems to be solved. Main open problems are related to performance, scalability, usability |
open problems to be solved. The most severe problems are related to performance, scalability, usability |
876 |
and security. More important, many techniques developed for traditional distributed |
and security. More important, many techniques developed for traditional distributed |
877 |
systems may no longer apply with Peer-to-Peer systems. Therefore, new solutions are |
systems may no longer apply with Peer-to-Peer systems. Therefore, new solutions are |
878 |
needed to make Peer-to-Peer systems more secure and efficient. |
needed to make Peer-to-Peer systems more secure and efficient. |
884 |
approach; \emph{network} of loosely structured systems is scalable, but the \emph{data lookup model} is not. |
approach; \emph{network} of loosely structured systems is scalable, but the \emph{data lookup model} is not. |
885 |
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 |
886 |
routing more flexible againts hostile attacks. Another key problems in tightly structured |
routing more flexible againts hostile attacks. Another key problems in tightly structured |
887 |
systems are the lack of keyword searches and support for heterogeneous peers. |
systems are the lack of keyword searches, support for heterogeneous peers and load balancing |
888 |
|
\cite{balakrishanarticle03lookupp2p}. |
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 but as |
research regarding anonymity, access control, data availability and data integrity but as |
893 |
we will observe, much more research work is required to solve security related issues. |
we state in the following sections, 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 |
|
|
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 the 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 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 |
911 |
authority for reliable authentication. As author arques in \cite{douceur02sybil}, without centralized authority, |
authority for reliable authentication. As author arques in \cite{douceur02sybil}, without centralized authority, |
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 whilce increasing the load of system. However, if Spam attack is combined with Sybil attack, obviously |
sent to network while 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 |
safely. 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). |
930 |
|
|
931 |
Traditional overload of targeted peers is best known form of distrubuted Denial of Service attack (DDoS). For example, |
Traditional overload of targeted peers is best known form of distrubuted Denial of Service attack (DDoS). For example, |
932 |
hostile entity can attempt to burden targetted peers with garbage packets. As a implication, peers may act |
hostile entity can attempt to burden targetted peers with garbage network packets. As a implication, peers may act |
933 |
incorrectly or stop working. DDoS attack may be very severe, especially if rate of replication and caching |
incorrectly or stop working. DDoS attack may be very severe, especially if rate of replication and caching |
934 |
in Peer-to-Peer system is low. This may lead to data loss in the Peer-to-Peer system. Daswani et al. |
in Peer-to-Peer system is low. This may lead to data loss in the Peer-to-Peer system. Daswani et al. |
935 |
\cite{daswani02queryflooddos} has done research regarding to this subject. Authors suggest efficient load balancing |
\cite{daswani02queryflooddos} has done research regarding to this subject. Authors suggest efficient load balancing |
950 |
Implementations include Advogato \cite{advogatourl}. None of the current proposals or implementations |
Implementations include Advogato \cite{advogatourl}. None of the current proposals or implementations |
951 |
based on reputation address trust in a reliable way. |
based on reputation address trust in a reliable way. |
952 |
|
|
953 |
Optimal solution for trust in Peer-to-Peer systems would be certificate based security methods. |
Optimal solution for trust in Peer-to-Peer systems would be certificate based security models. |
954 |
Quite recently, widely used Public Key Infrastructure (PKI) has been deployed in distributed |
Quite recently, widely used Public Key Infrastructure (PKI) has been deployed in distributed |
955 |
systems \cite{rivest96sdsi}, \cite{spkiworkinggroup}. PKI is an reliable technology for securing |
systems \cite{rivest96sdsi}, \cite{spkiworkinggroup}. PKI is an reliable technology for securing |
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 |
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 |
964 |
features of PKI to be fully usable yet. Furthermore, the hierarchy of SDSI/SPKI \cite{rivest96sdsi}, |
features of PKI to be fully usable yet. Furthermore, the hierarchy of SDSI/SPKI \cite{rivest96sdsi}, |
965 |
\cite{spkiworkinggroup} may a problem for Peer-to-Peer systems, in which hierarchy is intentionally missing. |
\cite{spkiworkinggroup} may be a problem for Peer-to-Peer systems, in which hierarchy is intentionally missing. |
966 |
|
|
967 |
For data integrity, on the other hand, there are few working solutions. Cryptographic content hashes |
For data integrity, on the other hand, there are few working solutions. Cryptographic content hashes |
968 |
\cite{fips-sha-1}, variations \cite{merkle87hashtree} and their implementation techniques \cite{mohr02thex}, |
\cite{fips-sha-1}, variations \cite{merkle87hashtree} and their implementation techniques \cite{mohr02thex}, |
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, 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, in where document was originally published. Document-anonymity |
982 |
means that peer doesn't know which data it is currently hosting. Finally, query-anonymity is a 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 serves |
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 raised by this property is one area of future work. |
986 |
|
|
987 |
With regard to anonymity in Peer-to-Peer systems, there has been done much research work both at network |
With regard to anonymity in Peer-to-Peer systems, there has been done much research work both at network |
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}. |
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 |
1064 |
probability of succesfull routing. |
probability of succesful routing. |
1065 |
|
|
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. 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 data 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 average of $O(\log{n})$ neighbors. |
participating peer must maintain average of $O(\log{n})$ neighbors. |
1070 |
|
|
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}. Most important, t |
Ross Lee graham lists several external threats againts Peer-to-Peer networks \cite{grahamp2psecurity}. Most important, |
1085 |
he list includes viruses and trojans. Currently, there are not even partial solutions |
the 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 fault tolerance 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 until |
would be distributed anti-virus software, but much more intensive research is required until |
1090 |
this kind of solution would be applicable. |
this kind of solution would be applicable. |
1108 |
originator starts a data lookup 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 data lookup. 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 |
1113 |
may not be fast when desired data item requires many consecutive flooding rounds. |
may not be fast when desired data item requires many consecutive flooding rounds. |
1114 |
|
|
1125 |
over its local content.}. Mutual index caching architecture, as proposed in |
over its local content.}. Mutual index caching architecture, as proposed in |
1126 |
\cite{osokine02distnetworks}, is one variation of local indices techique. |
\cite{osokine02distnetworks}, is one variation of local indices techique. |
1127 |
|
|
1128 |
In random walk approach \cite{lv02searchreplication}, peer forwards a query to |
In random walk approach \cite{lv02searchreplication}, peer forwards query to |
1129 |
randomly selected neighbor. The basic random walk approach decreases the |
randomly selected neighbor. The basic random walk approach decreases the |
1130 |
overhead generated by messages. On the other hand, basic random walk approach |
overhead generated by messages. On the other hand, basic random walk approach |
1131 |
has poor response time. As suggested in \cite{lv02searchreplication}, |
has poor response time. As suggested in \cite{lv02searchreplication}, |
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-Search (DFS) 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. Another property of Freenet's data lookup model is that |
1138 |
|
it adapts well with varying usage patterns. Improvements to Freenet's data lookup using |
1139 |
''small-world phenomenon'' has been proposed by Zhang et al.. \cite{zhang02using}. |
''small-world phenomenon'' has been proposed by Zhang et al.. \cite{zhang02using}. |
1140 |
|
|
1141 |
|
|
1166 |
been focused on tightly structured approach. |
been focused on tightly structured approach. |
1167 |
The main 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 |
1168 |
performs data lookups based on a globally unique identifier (key). Quite recent study has been focused |
performs data lookups based on a globally unique identifier (key). Quite recent study has been focused |
1169 |
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} on top of |
1170 |
argue, that it is possible to implement Peer-to-Peer Web-like search with certain radical compromises. |
tightly structured overlays. Authors argue, that it is possible to implement Peer-to-Peer Web-like search with certain radical compromises. |
1171 |
First, Peer-to-Peer search engine 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 |
1172 |
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 |
1173 |
better performance. |
better performance. |
1183 |
distributions\footnote{Zipf distribution is a variant of power-law function. |
distributions\footnote{Zipf distribution is a variant of power-law function. |
1184 |
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 |
1185 |
$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 |
1186 |
$a$ is close to unity.} (e.g., \cite{breslau98implications}), caching and precomputation |
$a$ is close to unity.} (e.g., \cite{breslau98implications}). Therefore, caching and precomputation |
1187 |
can be done for optimizting search indices \cite{li03feasibility}. Regular compression algorithms, |
can be done for optimizing search indices \cite{li03feasibility}. Regular compression algorithms, |
1188 |
Bloom filters \cite{362692}, vector space models \cite{CuencaAcuna2002DSIWorkshop} and view |
Bloom filters \cite{362692}, vector space models \cite{CuencaAcuna2002DSIWorkshop} and view |
1189 |
trees \cite{Bhattacharjee03resultcache} can be used for even better optimizations. Authors |
trees \cite{Bhattacharjee03resultcache} can be used for even better optimizations. Authors |
1190 |
in \cite{li03feasibility} use Gap compression \cite{wittengigabytes}, Adaptive Set Intersection \cite{338634} |
in \cite{li03feasibility} use Gap compression \cite{wittengigabytes}, Adaptive Set Intersection \cite{338634} |
1206 |
Peer-to-Peer system is \emph{never} in ''ideal'' state as it is always evolving system. |
Peer-to-Peer system is \emph{never} in ''ideal'' state as it is always evolving system. |
1207 |
|
|
1208 |
Current research has been focused on system management of tightly structured systems, since all presented |
Current research has been focused on system management of tightly structured systems, since all presented |
1209 |
algorithms of tightly structured approach have been analyzed under static simulation environments. Furthermore, propsed tightly structured |
algorithms of tightly structured approach have been analyzed under static simulation environments. Furthermore, proposed |
1210 |
overlays are configured statically to achieve the desired reliability even in uncommon and adverse environment |
tightly structured overlays are configured statically to achieve the desired reliability even in uncommon and adverse environment |
1211 |
\cite{rowston03controlloingreliability}. The most important factor for |
\cite{rowston03controlloingreliability}. The most important factor for |
1212 |
future research is to get real-life experiences from tightly structured system, when there are frequent |
future research is to get real-life experiences from tightly structured system, when there are frequent |
1213 |
joins and leaves in the system. Some research has been done already in this area. |
joins and leaves in the system. Some research has been done already in this area. |
1221 |
more efficient analytical tools for modelling complex Peer-to-Peer system. |
more efficient analytical tools for modelling complex Peer-to-Peer system. |
1222 |
|
|
1223 |
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 |
1224 |
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 data item is stored at the less loaded |
1225 |
of two (or more) random peer alternatives \cite{byers03dhtbalancing}. Rao et al. uses virtual servers |
of two (or more) random peer alternatives \cite{byers03dhtbalancing}. Rao et al. uses virtual servers |
1226 |
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 |
1227 |
idea which was originally introduced by Chord \cite{stoica01chord} system. |
idea which was originally introduced by Chord \cite{stoica01chord} system. |
1233 |
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. |
1234 |
|
|
1235 |
As mentioned before, 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 |
1236 |
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, e.g., in |
1237 |
face of computing power, or network bandwidth, data items are distributed uniformly. Clearly, this |
face of computing power or network bandwidth, all data items are distributed uniformly. Clearly, this |
1238 |
a serious problem of tightly structured overlays in face of performance and load balancing. Measurement study |
a serious problem of tightly structured overlays in face of performance and load balancing. Measurement study |
1239 |
by Saroiu et al. shows that there is extreme heterogeneity among participating peers in already deployed Peer-to-Peer |
by Saroiu et al. shows that there is extreme heterogeneity among participating peers in already deployed Peer-to-Peer |
1240 |
systems \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 |
1265 |
\subsection{Programming guidelines and benchmarks} |
\subsection{Programming guidelines and benchmarks} |
1266 |
|
|
1267 |
All existing Peer-to-Peer systems have rather different interfaces even they have common points and |
All existing Peer-to-Peer systems have rather different interfaces even they have common points and |
1268 |
components. More important, all existing Peer-to-Peer systems incompatible with each other. One |
components. More important, all existing Peer-to-Peer systems are incompatible with each other. One |
1269 |
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., |
1270 |
interfaces, design patters and frameworks. Also, equal benchmarks are needed for comparing |
interfaces, design patters and frameworks. Also, equal benchmarks are needed for comparing |
1271 |
different algorithms. Recently, there have been few proposals towards common programming |
different algorithms. Recently, there have been few proposals towards common programming |
1275 |
\subsection{Social behaviour} |
\subsection{Social behaviour} |
1276 |
|
|
1277 |
Frequent assumption in Peer-to-Peer systems is that peers are willing to cooperate. Another belief |
Frequent assumption in Peer-to-Peer systems is that peers are willing to cooperate. Another belief |
1278 |
is that all peers would behave equally, i.e. all peers both consume resources and contributes resources. |
is that all peers would behave equally, i.e., all peers both consume resources and contributes resources. |
1279 |
However, these assumptions are not true as several studies show peers rather consume than contribute and |
However, these assumptions are not true as several studies show peers rather consume than contribute and |
1280 |
and peers are unwilling to cooperate \cite{saroiu02measurementstudyp2p}, \cite{oram01harnessingpower}, |
and peers are unwilling to cooperate \cite{saroiu02measurementstudyp2p}, \cite{oram01harnessingpower}, |
1281 |
\cite{hearn02mojonation}. |
\cite{hearn02mojonation}. |
1301 |
rates. |
rates. |
1302 |
|
|
1303 |
As long as global simulations of Peer-to-Peer systems are lacking, we cannot we make any further |
As long as global simulations of Peer-to-Peer systems are lacking, we cannot we make any further |
1304 |
analysis e.g., on usage patterns in Peer-to-Peer systems. Presumedly, however, we can assume that |
analysis e.g., on usage patterns in Peer-to-Peer systems. However, we can assume that |
1305 |
, e.g., query keywords follow the Zipf-like distributions \cite{breslau98implications} both in the |
, e.g., query keywords follow the Zipf-like distributions \cite{breslau98implications} both in the |
1306 |
Internet and in Peer-to-Peer systems. |
Internet and in Peer-to-Peer systems. |
1307 |
|
|
1679 |
Xanalogical storage \cite{nelson99xanalogicalneeded} is a different kind of model for |
Xanalogical storage \cite{nelson99xanalogicalneeded} is a different kind of model for |
1680 |
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 |
1681 |
between \emph{documents}, in xanalogical model links are between individual |
between \emph{documents}, in xanalogical model links are between individual |
1682 |
\emph{characters}. Indeed, each character in xanalogical storage model has a |
\emph{characters}. Each character in xanalogical storage model has a |
1683 |
permanent, globally unique identifier. For instance, let's consider the following |
permanent, globally unique identifier. For instance, let's consider the following |
1684 |
scenario: ''the character 'D' typed by Janne Kujala on 10/8/97 8:37:18''. In this |
scenario: ''the character 'D' typed by Janne Kujala on 10/8/97 8:37:18''. In this |
1685 |
example, when character 'D' is is first typed in, xanalogical storage model |
example, when character 'D' is is first typed in, xanalogical storage model |
1698 |
\emph{Enfilade} can be considered as a ''virtual file'' (or part of one), which is a list |
\emph{Enfilade} can be considered as a ''virtual file'' (or part of one), which is a list |
1699 |
of fluid media contents. In xanalogical storage model, links between content are external |
of fluid media contents. In xanalogical storage model, links between content are external |
1700 |
and bidirectional. Xanadu link is an \emph{association} of two enfilades, such as an |
and bidirectional. Xanadu link is an \emph{association} of two enfilades, such as an |
1701 |
annotation to a specific part of a another document. Transclusion is an inclusion in an |
annotation to a specific part of a another document. \emph{Transclusion} is an inclusion in |
1702 |
enfilade of contents already used in another enfilade, i.e. current fluid media is copied into |
enfilade of contents already used in another enfilade, i.e., current fluid media is copied into |
1703 |
different data contents. By using this mechanism, system implementing xanalogical model |
different data contents. By using this mechanism, system implementing xanalogical storage model |
1704 |
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 |
1705 |
(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} |
1706 |
illustrates xanalogical storage model with documents, text and characters. |
illustrates xanalogical storage model with documents, text and characters. |
1750 |
associated 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 |
1751 |
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 |
1752 |
pointer creation process. Pointer block may contain zero or more obsoleted |
pointer creation process. Pointer block may contain zero or more obsoleted |
1753 |
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 |
1754 |
one older version which has been created in the past. The most current pointer |
one older version which has been created in the past. The most current pointer |
1755 |
block will 'obsolete' the pointer block targeting the supersed version. Next |
block will 'obsolete' the pointer block targeting the superseded version. Next |
1756 |
time, when the pointer is used for refering to a specific scroll block, only |
time, when the pointer is used for refering to a specific scroll block, only |
1757 |
the most recent pointer's block target is loaded. |
the most recent pointer's block target is loaded. |
1758 |
|
|
1770 |
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 |
1771 |
environment. We define Fenfire's special needs and evaluate existing |
environment. We define Fenfire's special needs and evaluate existing |
1772 |
Peer-to-Peer approaches in light of these requirements. After that, we propose system |
Peer-to-Peer approaches in light of these requirements. After that, we propose system |
1773 |
model for Fenfire in Peer-to-Peer environment, present simple algorithms to perform data |
model for Fenfire in Peer-to-Peer environment and present simple algorithms to perform data |
1774 |
lookups in Peer-to-Peer environment. Also, we discuss possible problems of using Fenfire |
lookups in Peer-to-Peer environment. In the end, we discuss possible problems of using Fenfire |
1775 |
in Peer-to-Peer environment |
in Peer-to-Peer environment |
1776 |
|
|
1777 |
|
|
1838 |
feature is almost analogical to Fenfire's (and xanalogical storage model's) way of |
feature is almost analogical to Fenfire's (and xanalogical storage model's) way of |
1839 |
handling data. Another key feature of tightly structured overlays is that they are able |
handling data. Another key feature of tightly structured overlays is that they are able |
1840 |
to provide general purpose \emph{interface} for Reference Resolution Services (RRS)\footnote{ |
to provide general purpose \emph{interface} for Reference Resolution Services (RRS)\footnote{ |
1841 |
Currently, Domain Name System (DNS) \cite{rfc1101} is widely used RRS system in the Internet.} |
Domain Name System (DNS) \cite{rfc1101} is widely used RRS system in the Internet.} |
1842 |
\cite{balakrishnan03semanticfree}. Authors argue that next generation RRS must be |
\cite{balakrishnan03semanticfree}. Authors argue that next generation RRS must be |
1843 |
application-independent and references itself should be \emph{unstructured} and |
application-independent and references itself should be \emph{unstructured} and |
1844 |
\emph{semantic free}. Finally, with tightly stuctured systems, it is feasible to |
\emph{semantic free}. Finally, as said, with tightly stuctured systems, it is feasible to |
1845 |
perform \emph{global} data lookups in the overlay. To summarize, these aspects may be the most important features |
perform \emph{global} data lookups in the overlay. To summarize, these aspects may be the most important features |
1846 |
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. |
1847 |
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 |
1899 |
|
|
1900 |
For better fault tolerance and self-monitoring for Fenfire, we propose techniques |
For better fault tolerance and self-monitoring for Fenfire, we propose techniques |
1901 |
presented by Rowston et al. \cite{rowston03controlloingreliability}. With these |
presented by Rowston et al. \cite{rowston03controlloingreliability}. With these |
1902 |
techniques, we can ensure the performance of Fenfire in a highly adverse environment, such |
techniques, we can ensure the performance of Fenfire in a highly adverse conditions, such |
1903 |
as extreme heterogeneous, higly dynamic environment or network partition. |
as sudden network partition, or highly dynamic and heterogeneous environment. |
1904 |
|
|
1905 |
Finally, for more efficient data transfer, we can use variable techniques for this purpose. |
Finally, for more efficient data transfer, we can use variable techniques for this purpose. |
1906 |
For small amounts of data, HTTP can be used \cite{rfc2068}. For big downloads, we can use |
For small amounts of data, HTTP can be used \cite{rfc2068}. For big downloads, we can use |
1909 |
|
|
1910 |
\subsection{Algorithms} |
\subsection{Algorithms} |
1911 |
|
|
1912 |
We use DOLR abstraction 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 |
1913 |
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 |
1914 |
model, since DOLR systems locate date without specifiying a storage policy explicity \cite{rhea03benchmarks}. |
model, since DOLR systems locate data without specifiying a storage policy explicity \cite{rhea03benchmarks}. |
1915 |
DHT based storage systems, such as CFS \cite{dabek01widearea} and PAST \cite{rowstron01storage}, may have |
DHT based storage systems, such as CFS \cite{dabek01widearea} and PAST \cite{rowstron01storage}, may have |
1916 |
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 |
1917 |
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 |
1937 |
\begin{itemize} |
\begin{itemize} |
1938 |
\item Data lookup with a given identifier of Storm scroll block. |
\item Data lookup with a given identifier of Storm scroll block. |
1939 |
\begin{enumerate} |
\begin{enumerate} |
1940 |
\item Submit query using scroll block's identifier. |
\item Submit data lookup using scroll block's identifier. |
1941 |
\item Repeat until hosting peer 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 data lookup to a closer peer which hosts the given scroll block identifier. |
1942 |
\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. |
1943 |
\item Query originator requests hosting peer to return the scroll block. |
\item Query originator requests hosting peer to return the scroll block. |
1944 |
\end{enumerate} |
\end{enumerate} |
1953 |
\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. |
1954 |
\begin{enumerate} |
\begin{enumerate} |
1955 |
\item Query originator locally compute a hash for given pointer random string. |
\item Query originator locally compute a hash for given pointer random string. |
1956 |
\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. |
\item Repeat until hosting peer is found: each peer forwards the data lookup to a closer peer which hosts the given hash of pointer random string. |
1957 |
\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. |
1958 |
\item Query originator requests hosting peer to return the scroll block. |
\item Query originator requests hosting peer to return the scroll block. |
1959 |
\end{enumerate} |
\end{enumerate} |
1964 |
\begin{enumerate} |
\begin{enumerate} |
1965 |
|
|
1966 |
\item Query originator locally compute a hash for given pointer random string. |
\item Query originator locally compute a hash for given pointer random string. |
1967 |
\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. |
\item Repeat until hosting peer is found: each peer forwards the data lookup to a closer peer which hosts the given hash of pointer random string. |
1968 |
\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. |
1969 |
\item Query originator requests hosting peer to return the scroll block. |
\item Query originator requests hosting peer to return the scroll block. |
1970 |
\end{enumerate} |
\end{enumerate} |
1973 |
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 |
1974 |
in a tightly structured overlay using DOLR method, where pointer random string is known. |
in a tightly structured overlay using DOLR method, where pointer random string is known. |
1975 |
|
|
1976 |
Each of these algortihms can locate Fenfire related data in $\Theta(\log{n})$ time: |
Each of these algortihms can locate Fenfire related data in $O(\log{n})$ time: |
1977 |
$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 |
1978 |
locating hosting peer with a given reference link. Time required for transferring |
locating hosting peer with a given reference link. Time required for transferring |
1979 |
the data is not included. |
the data is not included. |
1997 |
\subsection{Problems} |
\subsection{Problems} |
1998 |
|
|
1999 |
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 |
2000 |
secure techologies. For instance, online entities cannot be identified |
security techologies. For instance, online entities cannot be identified |
2001 |
safely (e.g., the Sybil attack \cite{douceur02sybil}). For Fenfire, one |
safely (e.g., the Sybil attack \cite{douceur02sybil}). For Fenfire, one |
2002 |
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 |
2003 |
pointer random string; how user is able to verify the correctness |
pointer random string; how user is able to verify the correctness |
2005 |
correct Storm scroll block ? Spam attack \cite{naor03simpledht} is a variation of previously |
correct Storm scroll block ? Spam attack \cite{naor03simpledht} is a variation of previously |
2006 |
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 |
2007 |
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 |
2008 |
data really no exist in the system ? Another problem related to Fenfire's |
data really doesn't exist in the system ? Another problem related to Fenfire's |
2009 |
security is that if a user downloads data from the network to local computer |
security is that if a user downloads data from the network to local computer |
2010 |
and after network disconnetcion, user wants to verify \emph{offline} the |
and after network disconnetcion, user wants to verify \emph{offline} the |
2011 |
authenticity of data. Obviously, optimal solution to all security issues would |
authenticity of data. Obviously, optimal solution to all security issues would |
2012 |
be that digital signatures are included to every message sent in the system. |
be that digital signatures are included to every message sent to the system. |
2013 |
However, these problems are not only limited to Fenfire, it concerns all |
However, these problems are not only limited to Fenfire, it concerns all |
2014 |
Peer-to-Peer based computer systems. |
Peer-to-Peer based computer systems. |
2015 |
|
|
2024 |
we divided open problems into three sub-categories: security related problems, |
we divided open problems into three sub-categories: security related problems, |
2025 |
performance related problems and miscellaneous problems. Each of these |
performance related problems and miscellaneous problems. Each of these |
2026 |
sub-categories have number of open problems, in which there are no solutions |
sub-categories have number of open problems, in which there are no solutions |
2027 |
yet, or solutions are only partial. Much research work is required to |
yet, or solutions are only partial. We point out that much research work is required to |
2028 |
solve open problems. |
solve open problems. |
2029 |
|
|
2030 |
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 |
2033 |
|
|
2034 |
In last chapter, we evaluated existing Peer-to-Peer approaches with regard |
In last chapter, we evaluated existing Peer-to-Peer approaches with regard |
2035 |
to Fenfire's needs. We proposed, that tightly structured approach is the |
to Fenfire's needs. We proposed, that tightly structured approach is the |
2036 |
best alternative to our needs for the following reasons. First, Storm, xanalogical |
best alternative to Fenfire's needs for the following reasons. First, Storm, xanalogical |
2037 |
model and tightly structured systems use global unique identifiers |
model and tightly structured systems use global unique identifiers |
2038 |
for identifying data. Second, our Storm design uses semantic-free references |
for identifying data. Second, our Storm design uses semantic-free references |
2039 |
for locating data in distributed networks. As the authors of \cite{balakrishnan03semanticfree}, |
for locating data in distributed networks generated by SHA-1 cryptographic content |
2040 |
we also observe that tightly structured overlays provide general purpose |
hash \cite{fips-sha-1}. As the authors of \cite{balakrishnan03semanticfree}, |
2041 |
interface to next-generation reference resolution services. Second, by using |
we also agree that tightly structured overlays provide general purpose |
2042 |
|
interface to next-generation reference resolution services. Third, by using |
2043 |
DOLR abstraction of tightly structured overlay, we can minimize the the lack |
DOLR abstraction of tightly structured overlay, we can minimize the the lack |
2044 |
of locality in tightly structured overlays. Finally, we believe that issues |
of locality in tightly structured overlays. Finally, we believe that issues |
2045 |
related to tightly structured overlays are solved in near future, because of |
related to tightly structured overlays are solved in near future, because of |