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 vertaisverkkoympäristössä} |
23 |
|
|
24 |
\author{Hermanni Hyytiälä} |
\author{Hermanni Hyytiälä} |
25 |
|
|
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- |
\avainsanat{Vertaisverkot, P2P, tietoturva, hajautetut järjestelmät, hypermedia järjestelmät} |
|
järjestelmät} |
|
33 |
|
|
34 |
\contactinformation{\\ |
\contactinformation{\\ |
35 |
Hermanni Hyytiälä\\ |
Hermanni Hyytiälä\\ |
176 |
In the loosely structured approach the construction and the maintenance of the overlay is controlled |
In the loosely structured approach the construction and the maintenance of the overlay is controlled |
177 |
loosely. The placement of services and the topology of overlay is random. The data lookup model in loosely structured systems is |
loosely. The placement of services and the topology of overlay is random. The data lookup model in loosely structured systems is |
178 |
not very efficient, because of unstructured properties of the overlay. Data lookup model is a combination of methods which |
not very efficient, because of unstructured properties of the overlay. Data lookup model is a combination of methods which |
179 |
are used for locatin data in the overlay. |
are used for locating data in the overlay. |
180 |
|
|
181 |
\subsection{Definition} |
\subsection{Definition} |
182 |
|
|
292 |
|
|
293 |
Partly due to scalability problems of loosely structured systems, several tightly |
Partly due to scalability problems of loosely structured systems, several tightly |
294 |
structured overlays have been proposed. In the tightly structured |
structured overlays have been proposed. In the tightly structured |
295 |
approach the overlay is constructed determistically, which all participating peers have to follow; the topology of the |
approach the overlay is constructed deterministically, which all participating peers have to follow; the topology of the |
296 |
overlay and the placement of services is controlled tightly. |
overlay and the placement of services is controlled tightly. |
297 |
|
|
298 |
\subsection{Definition} |
\subsection{Definition} |
310 |
which maps data items, expressed by an identifier to coordinate point $ip$ in $(IS,d)$. Peer's $p$ |
which maps data items, expressed by an identifier to coordinate point $ip$ in $(IS,d)$. Peer's $p$ |
311 |
resources are mapped onto a set $IS$ = \{$ip \in IS: \exists s \in S$, $ip = \zeta(\iota(s)) \wedge (\delta(s) = p)$\}. |
resources are mapped onto a set $IS$ = \{$ip \in IS: \exists s \in S$, $ip = \zeta(\iota(s)) \wedge (\delta(s) = p)$\}. |
312 |
Every $p$ has neighbor(s), named as $p_n$, $P$ = \{$p \in P: \exists p_n$, |
Every $p$ has neighbor(s), named as $p_n$, $P$ = \{$p \in P: \exists p_n$, |
313 |
where $\theta(p,p_n) = ''close''$, where $''close''$ is small difference $d$ in $(IS,d)$\}. |
where $\theta(p,p_n)$ = ''close'', and ''close'' is small difference $d$ in $(IS,d)$\}. |
314 |
|
|
315 |
\subsection{Systems} |
\subsection{Systems} |
316 |
|
|
317 |
With tightly structured systems, it is feasible to perform \emph{global} data lookups in the overlay efficiently. By global lookup, we mean |
With tightly structured systems, it is feasible to perform \emph{global} data lookups in the overlay efficiently. By global lookup, we mean |
318 |
that the system is able to find a service from the overlay, if it exists in the overlay. |
that the system is able to find a service from the overlay, if it exists in the overlay. |
319 |
While there are significant differences among proposed tighty structured systems, they all have in common |
While there are significant differences among proposed tightly structured systems, they all have in common |
320 |
that \emph{peer identifiers} are assigned to participating peers from |
that \emph{peer identifiers} are assigned to participating peers from |
321 |
a large \emph{identifier space} by the overlay. Globally unique identifiers |
a large \emph{identifier space} by the overlay. Globally unique identifiers |
322 |
are also assigned to application-specific data items, \emph{keys}, |
are also assigned to application-specific data items, \emph{keys}, |
819 |
In this chapter, we discuss open problems in Peer-to-Peer research. |
In this chapter, we discuss open problems in Peer-to-Peer research. |
820 |
Note that the open problems list considered here is not meant |
Note that the open problems list considered here is not meant |
821 |
to be an exhaustive survey of \emph{all} open problems in Peer-to-Peer domain; |
to be an exhaustive survey of \emph{all} open problems in Peer-to-Peer domain; |
822 |
we focus our attention to some issues related security, scalability, usability and performance. |
we focus our attention to some issues related to security, scalability, usability and performance. |
823 |
|
|
824 |
|
|
825 |
\section{Overview} |
\section{Overview} |
856 |
the Distributed Denial of Service attack. |
the Distributed Denial of Service attack. |
857 |
|
|
858 |
In the Sybil attack model \cite{douceur02sybil}, a hostile entity presents multiple |
In the Sybil attack model \cite{douceur02sybil}, a hostile entity presents multiple |
859 |
entities, i.e., when a peer communicates with a subset of other participating entities to perform a operation, a peer communicates |
entities, i.e., when a peer communicates with a subset of other participating entities to perform an operation, a peer communicates |
860 |
only with the same hostile entity. Hostile entity can control a large fraction of Peer-to-Peer system while |
only with the same hostile entity. Hostile entity can control a large fraction of Peer-to-Peer system while |
861 |
repressing the redundancy of the system. Authors argue in \cite{douceur02sybil} that without a centralized authority, Sybil attacks are always possible in a Peer-to-Peer |
repressing the redundancy of the system. Authors argue in \cite{douceur02sybil} that without a centralized authority, Sybil attacks are always possible in a Peer-to-Peer |
862 |
system except under extreme and unrealistic assumptions of resource parity and coordination among entities. Unrealistic assumptions include: all entities |
system except under extreme and unrealistic assumptions of resource parity and coordination among entities. Unrealistic assumptions include: all entities |
867 |
They call this method as a one form of \emph{self-certifying data}. |
They call this method as a one form of \emph{self-certifying data}. |
868 |
|
|
869 |
In the Fail-stop attack model, cited in \cite{naor03simpledht}, a faulty peer is deleted from the Peer-to-Peer system. Thus, |
In the Fail-stop attack model, cited in \cite{naor03simpledht}, a faulty peer is deleted from the Peer-to-Peer system. Thus, |
870 |
a specific data item can be lost from the system temporaraly (or permanently). The reason for the faultiness of a peer can be a |
a specific data item can be lost from the system temporarily (or permanently). The reason for the faultiness of a peer can be a |
871 |
software failure or a hostile attack. The Byzantine attack model \cite{357176} is closely related to Fail-stop model. In the Byzantine attack model |
software failure or a hostile attack. The Byzantine attack model \cite{357176} is closely related to Fail-stop model. In the Byzantine attack model |
872 |
$3f + 1$ is the minimum number of peers that allow system to provide the safety and liveness properties when up to $f$ peers are faulty \cite{357176}. |
$3f + 1$ is the minimum number of peers that allow system to provide the safety and liveness properties when up to $f$ peers are faulty \cite{357176}. |
873 |
The Byzantine model can be seen as more severe than Fail-stop model as there are no restrictions over the behavior of faulty peers, e.g., the cooperation |
The Byzantine model can be seen as more severe than Fail-stop model as there are no restrictions over the behavior of faulty peers, e.g., the cooperation |
875 |
proposed by Castro et al. \cite{296824}. Authors use in their work replication algorithm to tolerate Byzantine faults and cryptographic |
proposed by Castro et al. \cite{296824}. Authors use in their work replication algorithm to tolerate Byzantine faults and cryptographic |
876 |
certificate techniques to prevent spoofing and replays to detect corrupted messages. |
certificate techniques to prevent spoofing and replays to detect corrupted messages. |
877 |
|
|
878 |
The Spam generating attack \cite{naor03simpledht} is an another known attack model against Peer-to-Peer system. In the Spam |
The Spam generating attack \cite{naor03simpledht} is another known attack model against Peer-to-Peer system. In the Spam |
879 |
attack, a hostile or faulty peer may produce false information of the data, or refuses to (or is not able to) reply to requests. |
attack, a hostile or faulty peer may produce false information of the data, or refuses to (or is not able to) reply to requests. |
880 |
Naor et al. \cite{naor03simpledht} have proposed a partial solution against Spam attack in a \emph{faulty} peer environment (not hostile). |
Naor et al. \cite{naor03simpledht} have proposed a partial solution against Spam attack in a \emph{faulty} peer environment (not hostile). |
881 |
|
|
923 |
According to \cite{dingledine00free}, there exist several kinds of anonymity: author-anonymity, |
According to \cite{dingledine00free}, there exist several kinds of anonymity: author-anonymity, |
924 |
publisher-anonymity, reader-anonymity, peer-anonymity and query-ano-nymity. Author-anonymity is a form |
publisher-anonymity, reader-anonymity, peer-anonymity and query-ano-nymity. Author-anonymity is a form |
925 |
of anonymity in which no one can link author (who created the document) to a document. |
of anonymity in which no one can link author (who created the document) to a document. |
926 |
Publisher-anonymity means that no one is able to determine the publisher (how published the document into |
Publisher-anonymity means that no one is able to determine the publisher (who published the document into |
927 |
the system) of a document. Reader-anonymity means that a document cannot be linked to its readers. |
the system) of a document. Reader-anonymity means that a document cannot be linked to its readers. |
928 |
With peer-anonymity, no one is able to determine the peer, where the document was originally published. |
With peer-anonymity, no one is able to determine the peer, where the document was originally published. |
929 |
Document-anonymity means that a peer doesn't know which data it is currently hosting. Finally, query-anonymity is a form |
Document-anonymity means that a peer doesn't know which data it is currently hosting. Finally, query-anonymity is a form |
931 |
to the data lookup originators. As the authors of \cite{dingledine00free} cite, some forms of anonymity |
to the data lookup originators. As the authors of \cite{dingledine00free} cite, some forms of anonymity |
932 |
may imply each other and possible issues raised by this property is one area of future work. |
may imply each other and possible issues raised by this property is one area of future work. |
933 |
|
|
934 |
Obviously, existance of several types of anonymity often conflicts with other key properties of |
Obviously, existence of several types of anonymity often conflicts with other key properties of |
935 |
Peer-to-Peer systems. Let us consider anonymity and efficient data lookup. In efficient data lookup, we must know |
Peer-to-Peer systems. Let us consider anonymity and efficient data lookup. In efficient data lookup, we must know |
936 |
the peers responsible for given data. Of course, when we know the peers responsible |
the peers responsible for given data. Of course, when we know the peers responsible |
937 |
for the data, the anonymity of peer is lost. Fortunately, there are partial solutions to these kinds of |
for the data, the anonymity of peer is lost. Fortunately, there are partial solutions to these kinds of |
946 |
distributed systems which are able to provide some level of anonymity (e.g., \cite{mneturl}). |
distributed systems which are able to provide some level of anonymity (e.g., \cite{mneturl}). |
947 |
|
|
948 |
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 |
949 |
such a system which is able to provide complete anonymity in all levels (see above). Specifically, the conflicts |
such system which is able to provide complete anonymity in all levels (see above). Specifically, the conflicts |
950 |
between anonymity and other properties of Peer-to-Peer system require more research work. |
between anonymity and other properties of Peer-to-Peer system require more research work. |
951 |
|
|
952 |
|
|
970 |
\subsection{Hostile entities} |
\subsection{Hostile entities} |
971 |
|
|
972 |
One serious problem in Peer-to-Peer systems is the inability to distinguish hostile entities from regular entities |
One serious problem in Peer-to-Peer systems is the inability to distinguish hostile entities from regular entities |
973 |
trustworthy. Identification of hostile entities is essential in the tightly structured |
trustworthly. Identification of hostile entities is essential in the tightly structured |
974 |
approach, in which the fundamental (and implicit) assumption is that there is a random, uniform distribution |
approach, in which the fundamental (and implicit) assumption is that there is a random, uniform distribution |
975 |
of peer identifiers that cannot be controlled by a hostile entity. |
of peer identifiers that cannot be controlled by a hostile entity. |
976 |
|
|
977 |
One possible solution is to use a self-monitoring system, such as SOMO \cite{zhang03somo}, in which a self-monitoring overlay |
One possible solution is to use a self-monitoring system, such as SOMO \cite{zhang03somo}, in which a self-monitoring overlay |
978 |
constantly analyses the Peer-to-Peer overlay. Self-monitoring overlay is built on top of Peer-to-Peer overlay. Authors in |
constantly analyses the Peer-to-Peer overlay. Self-monitoring overlay is built on top of Peer-to-Peer overlay. Authors in |
979 |
\cite{sit02securitycons} suggest the use of system invariants. They emphasize that system invariants should be veriable, and if |
\cite{sit02securitycons} suggest the use of system invariants. They emphasize that system invariants should be verifiable, and if |
980 |
system invariants fail the system must have a recovery mechanism. In distributed peer identifier assignment \cite{castro02securerouting, clarke00freenet}, |
system invariants fail the system must have a recovery mechanism. In distributed peer identifier assignment \cite{castro02securerouting, clarke00freenet}, |
981 |
multiple participating peers participate in a creation of peer identifier. |
multiple participating peers participate in a creation of peer identifier. |
982 |
|
|
983 |
Centralized authorities could be used for the assignment of peer identifiers, but they may not be suitable |
Centralized authorities could be used for the assignment of peer identifiers, but they may not be suitable |
984 |
for ad hoc Peer-to-Peer environrment and have property of single point of failure. Distributed peer |
for ad hoc Peer-to-Peer environment and have property of single point of failure. Distributed peer |
985 |
identification assignment can be problematic as long as the Sybil attack \cite{douceur02sybil} remains unsolved. |
identification assignment can be problematic as long as the Sybil attack \cite{douceur02sybil} remains unsolved. |
986 |
However, there are some partial solutions for controlling the \emph{rate} at which hostile entity is able to obtain peer |
However, there are some partial solutions for controlling the \emph{rate} at which hostile entity is able to obtain peer |
987 |
identifier, such as crypto-based puzzles \cite{juels99clientpuzzles}. |
identifier, such as crypto-based puzzles \cite{juels99clientpuzzles}. |
1000 |
Authors argue in \cite{castro02securitystructured} that with the combination of |
Authors argue in \cite{castro02securitystructured} that with the combination of |
1001 |
secure peer identifer assignment, secure routing table maintenance and secure message forwarding |
secure peer identifer assignment, secure routing table maintenance and secure message forwarding |
1002 |
secure query routing in tightly structured systems is possible. Additionally, authors cite in \cite{castro02securerouting} |
secure query routing in tightly structured systems is possible. Additionally, authors cite in \cite{castro02securerouting} |
1003 |
that the probability of routing successfully between to arbitrary |
that the probability of routing successfully between arbitrary |
1004 |
correct peers is $(1-f)^{h-1}$, when a fraction $f$ of the other peers are faulty or hostile and where |
correct peers is $(1-f)^{h-1}$, when a fraction $f$ of the other peers are faulty or hostile and where |
1005 |
$h$ is the number of hops in the overlay. Sit and Morris \cite{sit02securitycons} discuss the possibility of |
$h$ is the number of hops in the overlay. Sit and Morris \cite{sit02securitycons} discuss the possibility of |
1006 |
allowing the query originator to observe lookup progress and cross-check routing tables using random queries to achieve |
allowing the query originator to observe lookup progress and cross-check routing tables using random queries to achieve |
1007 |
secure routing in tightly structured overlay. However, their |
secure routing in tightly structured overlay. However, their |
1008 |
approach is not very efficient, since this method creates lot of additional network traffic when |
approach is not very efficient, since this method creates lot of additional network traffic when |
1009 |
in function i.e., it is unknown if this techique is realizable in a efficient way. |
in function i.e., it is unknown if this technique is realizable in an efficient way. |
1010 |
Lynch et al. \cite{lynch02atomicdataaccess} propose a solution for secure routing table |
Lynch et al. \cite{lynch02atomicdataaccess} propose a solution for secure routing table |
1011 |
maintenance, but their solution seems to have two major problems according to \cite{castro02securitystructured}. |
maintenance, but their solution seems to have two major problems according to \cite{castro02securitystructured}. |
1012 |
First, the solution is very expensive even without faulty or hostile entities. Second, each group of replicas |
First, the solution is very expensive even without faulty or hostile entities. Second, each group of replicas |
1024 |
|
|
1025 |
Ross Lee Graham lists several external threats against Peer-to-Peer networks \cite{grahamp2psecurity}. Most important, |
Ross Lee Graham lists several external threats against Peer-to-Peer networks \cite{grahamp2psecurity}. Most important, |
1026 |
the 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 |
1027 |
to the problems mentioned above. The reason for this is that there are no experience about these kinds of |
to the problems mentioned above. The reason for this is that there is no experience about these kinds of |
1028 |
attacks. Possible solution would be a distributed anti-virus software, but much more intensive research is required until |
attacks. Possible solution would be a distributed anti-virus software, but much more intensive research is required until |
1029 |
this kind of solution would be applicable. |
this kind of solution would be applicable. |
1030 |
|
|
1118 |
\parbox{90pt}{Access Control \cite{nejdl03accesscontrol, daswani03openproblems}} & |
\parbox{90pt}{Access Control \cite{nejdl03accesscontrol, daswani03openproblems}} & |
1119 |
\parbox{110pt}{Can we define access control levels in Peer-to-Peer network ?} & |
\parbox{110pt}{Can we define access control levels in Peer-to-Peer network ?} & |
1120 |
\parbox{110pt}{Schema-based rules} & |
\parbox{110pt}{Schema-based rules} & |
1121 |
\parbox{110pt}{Some initial experiences, need more research} |
\parbox{110pt}{Some initial experiences, needs more research} |
1122 |
\\ \hline |
\\ \hline |
1123 |
|
|
1124 |
|
|
1139 |
\parbox{90pt}{External security threats \cite{grahamp2psecurity}} & |
\parbox{90pt}{External security threats \cite{grahamp2psecurity}} & |
1140 |
\parbox{110pt}{Viruses, trojans, sniffers} & |
\parbox{110pt}{Viruses, trojans, sniffers} & |
1141 |
\parbox{110pt}{Data integrity/authenticity, distributed anti virus software} & |
\parbox{110pt}{Data integrity/authenticity, distributed anti virus software} & |
1142 |
\parbox{110pt}{Not much research has been done on this} |
\parbox{110pt}{Not much research has been done on this area} |
1143 |
\\ \hline |
\\ \hline |
1144 |
|
|
1145 |
\caption{Security problems in Peer-to-Peer.} |
\caption{Security problems in Peer-to-Peer.} |
1167 |
with successively larger TTL depth limits, until either the query is satisfied, |
with successively larger TTL depth limits, until either the query is satisfied, |
1168 |
or the maximum depth $D$ has been reached. Expanding ring, proposed by Shenker et al. in \cite{lv02searchreplication}, |
or the maximum depth $D$ has been reached. Expanding ring, proposed by Shenker et al. in \cite{lv02searchreplication}, |
1169 |
is similar to the iterative deepening technique. In this method, a peer starts a flood with small TTL, and |
is similar to the iterative deepening technique. In this method, a peer starts a flood with small TTL, and |
1170 |
waits to see if the search is successful. If it is, then the peer stops the data lookuo. Otherwise, the peer increases |
waits to see if the search is successful. If it is, then the peer stops the data lookup. Otherwise, the peer increases |
1171 |
the TTL and starts another data lookup. With these techniques, searches |
the TTL and starts another data lookup. With these techniques, searches |
1172 |
may not be fast when desired data item requires several consecutive flooding rounds. |
may not be fast when desired data item requires several consecutive flooding rounds. |
1173 |
|
|
1176 |
thereby maintaining the quality of costs and decreasing the amount |
thereby maintaining the quality of costs and decreasing the amount |
1177 |
of messages sent to network. |
of messages sent to network. |
1178 |
|
|
1179 |
In the local indices techique \cite{yang02improvingsearch}, each peer maintains an index over the data of all peers within |
In the local indices technique \cite{yang02improvingsearch}, each peer maintains an index over the data of all peers within |
1180 |
$h$ hops of itself, where $h$ is a system-wide variable, called radius of the |
$h$ hops of itself, where $h$ is a system-wide variable, called radius of the |
1181 |
index\footnote{In the normal BFS case, the value of $h$ is 0, as a peer only has index |
index\footnote{In the normal BFS case, the value of $h$ is 0, as a peer only has index |
1182 |
over its local content.}. Thus, when a peer receives a data lookup request, it can |
over its local content.}. Thus, when a peer receives a data lookup request, it can |
1195 |
Depth-First-Search (DFS) and peers' routing tables are dynamically built |
Depth-First-Search (DFS) and peers' routing tables are dynamically built |
1196 |
using caching. This is an outcome of Freenet's main design principles, anonymity. |
using caching. This is an outcome of Freenet's main design principles, anonymity. |
1197 |
Another property of the Freenet's data lookup model is that |
Another property of the Freenet's data lookup model is that |
1198 |
it adapts well with varying usage patterns (e.g., searching for popular data items in the overlay). |
it adapts well to varying usage patterns (e.g., searching for popular data items in the overlay). |
1199 |
Improvements to Freenet's data lookup using |
Improvements to Freenet's data lookup using |
1200 |
the ''small-world'' techniques have been proposed by Zhang et al. \cite{zhang02using}. |
the ''small-world'' techniques have been proposed by Zhang et al. \cite{zhang02using}. |
1201 |
|
|
1236 |
is designed for the CAN system \cite{ratnasamy01can}. |
is designed for the CAN system \cite{ratnasamy01can}. |
1237 |
|
|
1238 |
Recent study has been focused on the feasibility of Peer-to-Peer Web-like indexing and searching |
Recent study has been focused on the feasibility of Peer-to-Peer Web-like indexing and searching |
1239 |
on top of tightly structured overlays \cite{li03feasibility} . Authors argue, that it is possible to implement |
on top of tightly structured overlays \cite{li03feasibility}. Authors argue, that it is possible to implement |
1240 |
Peer-to-Peer Web-like search with certain compromises. First, Peer-to-Peer search engine may need to |
Peer-to-Peer Web-like search with certain compromises. First, Peer-to-Peer search engine may need to |
1241 |
decrease the result quality in order to make searching more efficient. Second, Peer-to-Peer systems must |
decrease the result quality in order to make searching more efficient. Second, Peer-to-Peer systems must |
1242 |
consult the properties of underlying network for better performance. |
consult the properties of underlying network for better performance. |
1269 |
Almost all presented algorithms |
Almost all presented algorithms |
1270 |
for the tightly structured systems have been analyzed under static simulation |
for the tightly structured systems have been analyzed under static simulation |
1271 |
environments \cite{libennowell01observations}. Furthermore, proposed tightly structured overlays are configured statically to achieve |
environments \cite{libennowell01observations}. Furthermore, proposed tightly structured overlays are configured statically to achieve |
1272 |
the desired reliability even in a uncommon and adverse environment \cite{rowston03controlloingreliability}. |
the desired reliability even in an uncommon and adverse environment \cite{rowston03controlloingreliability}. |
1273 |
Thus, one of the most important factors for future research is to get real-life experiences from tightly structured |
Thus, one of the most important factors for future research is to get real-life experiences from tightly structured |
1274 |
systems, when there are frequent joins and leaves of peers in the system. |
systems, when there are frequent joins and leaves of peers in the system. |
1275 |
|
|
1277 |
distribution of peer and key identifiers. Even if participating peers are extremely heterogeneous, e.g., in |
distribution of peer and key identifiers. Even if participating peers are extremely heterogeneous, e.g., in |
1278 |
computing power or network bandwidth, all data items are distributed uniformly. Clearly, this is |
computing power or network bandwidth, all data items are distributed uniformly. Clearly, this is |
1279 |
a serious problem of tightly structured overlays in face of performance and load balancing \cite{rao03loadbalancing}. |
a serious problem of tightly structured overlays in face of performance and load balancing \cite{rao03loadbalancing}. |
1280 |
Measurement study by Saroiu et al. show that there is a extreme heterogeneity among participating peers in already deployed Peer-to-Peer |
Measurement study by Saroiu et al. show that there is extreme heterogeneity among participating peers in already deployed Peer-to-Peer |
1281 |
systems \cite{saroiu02measurementstudyp2p}. |
systems \cite{saroiu02measurementstudyp2p}. |
1282 |
|
|
1283 |
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 |
1298 |
Hot spots happen, when a specific key is being requested extremely often in tightly structured overlays. Recent study |
Hot spots happen, when a specific key is being requested extremely often in tightly structured overlays. Recent study |
1299 |
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 |
1300 |
\cite{sloppy:iptps03}. Authors' technique is especially suitable for the DOLR abstraction of tightly structured overlays. |
\cite{sloppy:iptps03}. Authors' technique is especially suitable for the DOLR abstraction of tightly structured overlays. |
1301 |
They arque that with Sloppy hashing, the generation of query hot spots can be reduced and peers are able |
They argue that with Sloppy hashing, the generation of query hot spots can be reduced and peers are able |
1302 |
locate nearby data without looking up data from distant peers. Moreover, authors' |
locate nearby data without looking up data from distant peers. |
|
proposal for self-organizing clusters using network diameters. |
|
1303 |
|
|
1304 |
The concept of ''half-life'' was introduced by Liben-Nowell \cite{libennowell01observations} since Peer-to-Peer |
The concept of ''half-life'' was introduced by Liben-Nowell \cite{libennowell01observations} since Peer-to-Peer |
1305 |
system is \emph{never} in the ''ideal'' state as Peer-to-Peer system is continiously evolving system. Half-life is defined |
system is \emph{never} in the ''ideal'' state as Peer-to-Peer system is continuously evolving system. Half-life is defined |
1306 |
as follows: let there be $N$ live peers at time $t$. The doubling from time $t$ is the time that pass before |
as follows: let there be $N$ live peers at time $t$. The doubling from time $t$ is the time that pass before |
1307 |
$N$ new additional peers arrive into the system. The halving time from time $t$ is the time |
$N$ new additional peers arrive into the system. The halving time from time $t$ is the time |
1308 |
required for half of the living peers at time $t$ to leave the system. The half-life from |
required for half of the living peers at time $t$ to leave the system. The half-life from |
1313 |
Finally, little research has been done regarding self-monitoring. Zhang et al. |
Finally, little research has been done regarding self-monitoring. Zhang et al. |
1314 |
describe an arbitrary data structure on top of a tightly structured overlay \cite{zhang03somo}. Authors |
describe an arbitrary data structure on top of a tightly structured overlay \cite{zhang03somo}. Authors |
1315 |
call their technique as a \emph{data overlay}, since it supports several fundamental data structures. |
call their technique as a \emph{data overlay}, since it supports several fundamental data structures. |
1316 |
Authors have used this data overlay when building a Self-Organized Meta data Overlay (SOMO), which can be used |
Authors have used this data overlay when building a Self-Organized Metadata Overlay (SOMO), which can be used |
1317 |
for monitoring the health of a tightly structured overlay. The fault tolerance of SOMO itself is currently |
for monitoring the health of a tightly structured overlay. The fault tolerance of SOMO itself is currently |
1318 |
unknown. |
unknown. |
1319 |
|
|
1358 |
ramanathan02goodpeers, kleinberg99small, nips02-Kleinberg, zhang02using, watts00dynamics, karger02findingnearest, |
ramanathan02goodpeers, kleinberg99small, nips02-Kleinberg, zhang02using, watts00dynamics, karger02findingnearest, |
1359 |
brinkmann02compactplacement, rhea02probabilistic, castro02networkproximity, ng02predicting, pias03lighthouse, waterhouse02searchp2p, botros01jxtasearch, |
brinkmann02compactplacement, rhea02probabilistic, castro02networkproximity, ng02predicting, pias03lighthouse, waterhouse02searchp2p, botros01jxtasearch, |
1360 |
ganesan02yappers}} & |
ganesan02yappers}} & |
1361 |
\parbox{110pt}{Find resources efficiently, if resource exists (loosely structured)} & |
\parbox{110pt}{Find resource efficiently, if resource exists (loosely structured)} & |
1362 |
\parbox{110pt}{Super peers, peer clusters, caching techniques} & |
\parbox{110pt}{Super peers, peer clusters, caching techniques} & |
1363 |
\parbox{110pt}{More efficient, less network traffic, not comparable to the efficiency of tightly structured systems} |
\parbox{110pt}{More efficient, less network traffic, not comparable to the efficiency of tightly structured systems} |
1364 |
\\ \hline |
\\ \hline |
1461 |
All existing Peer-to-Peer systems have rather different interfaces even though they have common properties and |
All existing Peer-to-Peer systems have rather different interfaces even though they have common properties and |
1462 |
components (e.g., \cite{zhao03api}). More important, all existing Peer-to-Peer systems are incompatible with each other. One |
components (e.g., \cite{zhao03api}). More important, all existing Peer-to-Peer systems are incompatible with each other. One |
1463 |
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., |
1464 |
interfaces, design patters and frameworks. Also, benchmarks are needed for comparing |
interfaces, design patterns and frameworks. Also, benchmarks are needed for comparing |
1465 |
the efficiency of different algorithms equally. |
the efficiency of different algorithms equally. |
1466 |
|
|
1467 |
Recently, there have been few proposals towards common programming guidelines. Authors in |
Recently, there have been few proposals towards common programming guidelines. Authors in |
1468 |
\cite{zhao03api} propose a higher level abstracions for tightly structured overlays. Frise et al. suggest the use of |
\cite{zhao03api} propose a higher level abstractions for tightly structured overlays. Frise et al. suggest the use of |
1469 |
additional layer in Peer-to-Peer system to hide the structure of the overlay \cite{frise02p2pframework}. |
additional layer in Peer-to-Peer system to hide the structure of the overlay \cite{frise02p2pframework}. |
1470 |
With their abstraction, both the tightly structured and tightly structured approach can be used in the system. |
With their abstraction, both the loosely structured and tightly structured approach can be used in the system. |
1471 |
Montresor proposes a framework supporting developers and researchers in the design of Peer-to-Peer system |
Montresor proposes a framework supporting developers and researchers in the design of Peer-to-Peer system |
1472 |
\cite{babaoglu02anthill}. |
\cite{babaoglu02anthill}. |
1473 |
|
|
1551 |
|
|
1552 |
\parbox{90pt}{Heterogeneity \cite{saroiu02measurementstudyp2p, brinkmann02compactplacement, zhao02brocade, gurmeet03symphony, rowston03controlloingreliability}} & |
\parbox{90pt}{Heterogeneity \cite{saroiu02measurementstudyp2p, brinkmann02compactplacement, zhao02brocade, gurmeet03symphony, rowston03controlloingreliability}} & |
1553 |
\parbox{110pt}{There are different kind of peers in the system, in light of bandwidth and computing power} & |
\parbox{110pt}{There are different kind of peers in the system, in light of bandwidth and computing power} & |
1554 |
\parbox{110pt}{Super peers (loosely structured), clusters (loosely structured) additional layer upon tighty structured systems, structure itself is simple (tighty structured)} & |
\parbox{110pt}{Super peers (loosely structured), clusters (loosely structured) additional layer upon tighty structured systems, structure itself is simple (tightly structured)} & |
1555 |
\parbox{110pt}{Working solutions, increases system complexity (additional layer)} |
\parbox{110pt}{Working solutions, increases system complexity (additional layer)} |
1556 |
\\ \hline |
\\ \hline |
1557 |
|
|
1579 |
\parbox{90pt}{Locating Peer-to-Peer network} & |
\parbox{90pt}{Locating Peer-to-Peer network} & |
1580 |
\parbox{110pt}{How old peers or new peers are able to locate Peer-to-Peer network, if it exists} & |
\parbox{110pt}{How old peers or new peers are able to locate Peer-to-Peer network, if it exists} & |
1581 |
\parbox{110pt}{Servers maintaining online peers (e.g. gnutellahosts.com), peer's history information} & |
\parbox{110pt}{Servers maintaining online peers (e.g. gnutellahosts.com), peer's history information} & |
1582 |
\parbox{110pt}{Depends on implementation and purpose of the system, for a desktop system there are working solutions, for mobile ad hoc networks more research is needed (Mobile ad hoc |
\parbox{110pt}{Depends on implementation and purpose of the system, for a desktop system there are working solutions} |
|
networks (MANETs) can be only connected through radio resource interface, i.e., peers which are in same geographical area)} |
|
1583 |
\\ \hline |
\\ \hline |
1584 |
|
|
1585 |
\caption{Miscellaneous problems in Peer-to-Peer.} |
\caption{Miscellaneous problems in Peer-to-Peer.} |
1600 |
The Fenfire project \cite{fenfireurl} is an effort to build a location transparent, hyperstructured desktop |
The Fenfire project \cite{fenfireurl} is an effort to build a location transparent, hyperstructured desktop |
1601 |
environment. By location transparent, we mean hiding the heterogeneous and distributed nature of the system |
environment. By location transparent, we mean hiding the heterogeneous and distributed nature of the system |
1602 |
so that it appears to the end user like one system and by hyperstructured system |
so that it appears to the end user like one system and by hyperstructured system |
1603 |
a system in which data can be associated with other data arbitrarly. Fenfire uses xanalogical storage model |
a system in which data can be associated with other data arbitrarily. Fenfire uses xanalogical storage model |
1604 |
\cite{ted-xu-model} as a basis for hyperstructured media. Each data item in the Fenfire system has a globally unique |
\cite{ted-xu-model} as a basis for hyperstructured media. Each data item in the Fenfire system has a globally unique |
1605 |
identifier. This property should allow making references between \emph{any} |
identifier. This property should allow making references between \emph{any} |
1606 |
data easier and more seamlessly interoperating than in other systems. For location transparency in the Fenfire system, |
data easier and more seamlessly interoperating than in other systems. For location transparency in the Fenfire system, |
1633 |
characters\footnote{Xanalogical storage model |
characters\footnote{Xanalogical storage model |
1634 |
is not limited to text. It can support arbitrary data, e.g., pixels of picture or |
is not limited to text. It can support arbitrary data, e.g., pixels of picture or |
1635 |
frames of video.}. \emph{Enfilade} is a mutable ''virtual file'' (or part of one), which is a list |
frames of video.}. \emph{Enfilade} is a mutable ''virtual file'' (or part of one), which is a list |
1636 |
of fluid media content. Fluid media is the smallest units of data in the xanalogical storage |
of fluid media content. Fluid media is the smallest unit of data in the xanalogical storage |
1637 |
model (e.g., a character). \emph{Transclusion} is an inclusion in |
model (e.g., a character). \emph{Transclusion} is an inclusion in |
1638 |
enfilade of contents already used in another enfilade. With the transclusion, a system |
enfilade of contents already used in another enfilade. With the transclusion, a system |
1639 |
implementing the xanalogical storage model is able to show \emph{all} data content that share the same |
implementing the xanalogical storage model is able to show \emph{all} data content that share the same |
1649 |
example, presented first time in \cite{lukka02freenetguids}: ''the character 'D' |
example, presented first time in \cite{lukka02freenetguids}: ''the character 'D' |
1650 |
typed by Janne Kujala on 10/8/97 8:37:18''. When character |
typed by Janne Kujala on 10/8/97 8:37:18''. When character |
1651 |
'D' is first typed in, the xanalogical storage model |
'D' is first typed in, the xanalogical storage model |
1652 |
creates a permanent globally identifier for that character |
creates a permanent identifier for that character |
1653 |
and retains it when the character is copied to different document. In practice, the xanalogical |
and retains it when the character is copied to different document. In practice, the xanalogical |
1654 |
storage model uses \emph{spans}, ranges of consecutive |
storage model uses \emph{spans}, ranges of consecutive |
1655 |
fluid media units to perform storage operations. |
fluid media units to perform storage operations. |
1676 |
considered as a collision free hash function. Therefore, it is very unlikely that two different Storm data blocks |
considered as a collision free hash function. Therefore, it is very unlikely that two different Storm data blocks |
1677 |
would have same identifier.} \cite{fips-sha-1} is used |
would have same identifier.} \cite{fips-sha-1} is used |
1678 |
for creating unstructured and semantic-free, globally unique identifiers for blocks. Because of SHA-1 |
for creating unstructured and semantic-free, globally unique identifiers for blocks. Because of SHA-1 |
1679 |
content hash, all identifiers are directly the data verifiers as well. The uniquess of blocks creates |
content hash, all identifiers are directly the data verifiers as well. The uniqueness of blocks creates |
1680 |
a basis for implementing the xanalogical storage model in the Fenfire system. Storm blocks have in common with regular files as they |
a basis for implementing the xanalogical storage model in the Fenfire system. Storm blocks have in common with regular files as they |
1681 |
both contain the data. The main difference is that Storm blocks are \emph{immutable} since any |
both contain the data. The main difference is that Storm blocks are \emph{immutable} since any |
1682 |
change to the byte sequence would change block's hash value (i.e., globally unique identifier). |
change to the byte sequence would change block's hash value (i.e., globally unique identifier). |
1778 |
respond to fetching of Storm blocks as fetching can be performed easily once |
respond to fetching of Storm blocks as fetching can be performed easily once |
1779 |
Storm block is located. |
Storm block is located. |
1780 |
|
|
1781 |
In chapter 2, we discussed main the differences between the loosely and the tightly structured |
In chapter 2, we discussed the main differences between the loosely and the tightly structured |
1782 |
approach. As stated, the most significant difference is that the tightly structured |
approach. As stated, the most significant difference is that the tightly structured |
1783 |
approach has at least poly-logarithmical properties in all internal operations, while the loosely |
approach has at least poly-logarithmical properties in all internal operations, while the loosely |
1784 |
structured approach doesn't always have even linear properties. Furthermore, the |
structured approach doesn't always have even linear properties. Furthermore, the |
1922 |
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 |
1923 |
and after a network disconnection, user wants to verify \emph{off line} the |
and after a network disconnection, user wants to verify \emph{off line} the |
1924 |
authenticity of data. Finally, if a data lookup is performed by a user, but there is no reply |
authenticity of data. Finally, if a data lookup is performed by a user, but there is no reply |
1925 |
from the Fenfire system, how are we able to know if this was the Spam attack \cite{naor03simpledht}, |
from the Fenfire system, how are we able to know if this was a Spam attack \cite{naor03simpledht}, |
1926 |
or the data really doesn't exist in the system ? |
or the data really doesn't exist in the system ? |
1927 |
These problems, however, are not only limited to the Fenfire system as it |
These problems, however, are not only limited to the Fenfire system as it |
1928 |
concerns all Peer-to-Peer computer systems. |
concerns all Peer-to-Peer computer systems. |