237 |
forwards the query to their neighbors. This leads to a situation where number of messages |
forwards the query to their neighbors. This leads to a situation where number of messages |
238 |
in the network can grow with $O(n^{2})$, where $n$ is the number of participating peers in |
in the network can grow with $O(n^{2})$, where $n$ is the number of participating peers in |
239 |
Gnutella network. To limit the amount of network traffic, Gnutella uses Time-To-Live-limited |
Gnutella network. To limit the amount of network traffic, Gnutella uses Time-To-Live-limited |
240 |
(TTL) flooding to distributed queries. Therefore, Gnutella uses a Breadth-First-Search (BFS) algorithm |
(TTL) flooding to distribute queries. Therefore, Gnutella uses a Breadth-First-Search (BFS) algorithm |
241 |
with depth limit $T$ (e.g., 7), where $T$ is the system-wide maximum TTL of a message in hops. Thus, |
with depth limit $T$ (e.g., 7), where $T$ is the system-wide maximum TTL of a message in hops. Thus, |
242 |
only peers that are TTL hops away from the query originator will forward the query or respond to the query. |
only peers that are TTL hops away from the query originator will forward the query or respond to the query. |
243 |
In Gnutella network, search results are fast, because BFS sends queries to |
In Gnutella network, search results are fast, because BFS sends queries to |
334 |
The biggest difference compared to loosely structured approach is that with tightly structured systems, |
The biggest difference compared to loosely structured approach is that with tightly structured systems, |
335 |
it is now feasible to perform \emph{global} data lookups in the overlay. |
it is now feasible to perform \emph{global} data lookups in the overlay. |
336 |
While there are significant differences among proposed systems, they all have in common |
While there are significant differences among proposed systems, they all have in common |
337 |
that \emph{peer identifiers} is assigned to participating peers from |
that \emph{peer identifiers} are assigned to participating peers from |
338 |
a large \emph{identifier space} by the overlay. Furthermore, application-specific |
a large \emph{identifier space} by the overlay. Furthermore, application-specific |
339 |
data items are also assigned globally unique identifiers, \emph{keys}, |
data items are also assigned globally unique identifiers, \emph{keys}, |
340 |
which are selected from the same identifier space. The form of identifier |
which are selected from the same identifier space. The form of identifier |
366 |
peer identifier is gradually ''closer'' to the key's identifier |
peer identifier is gradually ''closer'' to the key's identifier |
367 |
in the identifier space. Distance can be measured by numerical |
in the identifier space. Distance can be measured by numerical |
368 |
difference between identifiers (e.g., Chord \cite{stoica01chord}), the number of |
difference between identifiers (e.g., Chord \cite{stoica01chord}), the number of |
369 |
same prefix bits between identifiers (e.g., Pastry \cite{rowston01pastry} and Tapestry \cite{zhao01tapestry}), |
same prefix bits between identifiers (e.g., Pastry \cite{rowston01pastry} and Tapestry \cite{zhao01tapestry}) or |
370 |
bit-wise exclusive or (XOR) (e.g., Kademlia \cite{maymounkov02kademlia}). |
bit-wise exclusive or (XOR) (e.g., Kademlia \cite{maymounkov02kademlia}). |
371 |
Because of XOR-metric, Kademlia's distance function is both unidirectional |
Because of XOR-metric, Kademlia's distance function is both unidirectional |
372 |
(for a given point $p_i$ in the identifier space and distance $d$ > 0, there |
(for a given point $p_i$ in the identifier space and distance $d$ > 0, there |
387 |
overlay, but in which queries are routed to \emph{keys}. In these systems |
overlay, but in which queries are routed to \emph{keys}. In these systems |
388 |
peer occupies several positions in the identifier space, one for each |
peer occupies several positions in the identifier space, one for each |
389 |
application-specific key. The indirection of placing close keys in the |
application-specific key. The indirection of placing close keys in the |
390 |
custody of a storing peer\footnote{Storing peer is the peer in the overlay which stores the |
custody of a storing peer\footnote{Storing peer is the peer in the overlay which is responsible for the |
391 |
assigned keys.} keys is removed at the cost of each peer maintaining one |
assigned keys.} keys is removed at the cost of each peer maintaining one |
392 |
''resource peer'' in the overlay network for each resource item pair it publishes. |
''resource peer'' in the overlay network for each resource item pair it publishes. |
393 |
|
|
588 |
\\ \hline |
\\ \hline |
589 |
|
|
590 |
\parbox{90pt}{Construction and maintenance of overlay} & |
\parbox{90pt}{Construction and maintenance of overlay} & |
591 |
\parbox{100pt}{uncontrolled and ad hoc} & |
\parbox{100pt}{Uncontrolled and ad hoc} & |
592 |
\parbox{100pt}{Controlled and structured} |
\parbox{100pt}{Controlled and structured} |
593 |
\\ \hline |
\\ \hline |
594 |
|
|
2016 |
\chapter{Conclusions and future work} |
\chapter{Conclusions and future work} |
2017 |
|
|
2018 |
In this thesis, we have reviewed existing Peer-to-Peer approaches, algorithms and |
In this thesis, we have reviewed existing Peer-to-Peer approaches, algorithms and |
2019 |
their properties. Currently, two main Peer-to-Peer overlay approaches |
their properties. We summarized open problems in Peer-to-Peer networks. Specifically, |
|
exist: loosely and tightly structured overlays. We have discussed differences, |
|
|
disadvantages and advantages of both approaches. |
|
|
|
|
|
After that, we summarized open problems in Peer-to-Peer networks. Specifically, |
|
2020 |
we divided open problems into three sub-categories: security related problems, |
we divided open problems into three sub-categories: security related problems, |
2021 |
performance related problems and miscellaneous problems. Each of these |
performance related problems and miscellaneous problems. Each of these |
2022 |
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 |
overview of Fenfire and xanalogical model. We also described Storm, |
overview of Fenfire and xanalogical model. We also described Storm, |
2028 |
which is an essential part of Fenfire's Peer-to-Peer functionality. |
which is an essential part of Fenfire's Peer-to-Peer functionality. |
2029 |
|
|
2030 |
In last chapter, we evaluated existing Peer-to-Peer approaches with regard |
In the last chapter, we evaluated existing Peer-to-Peer approaches with regard |
2031 |
to Fenfire's needs. We proposed, that tightly structured approach is the |
to Fenfire's needs. We proposed that tightly structured approach is the |
2032 |
best alternative to Fenfire's needs for the following reasons. First, Storm, xanalogical |
best alternative to Fenfire's needs for the following reasons. First, Storm, xanalogical |
2033 |
model and tightly structured systems use global unique identifiers |
model and tightly structured systems use global unique identifiers |
2034 |
for identifying data. Second, our Storm design uses \emph{semantic-free references} |
for identifying data. Second, our Storm design uses \emph{semantic-free references} |
2038 |
we also agree that tightly structured overlays provide general purpose |
we also agree that tightly structured overlays provide general purpose |
2039 |
interface to next-generation reference resolution services. Third, by using |
interface to next-generation reference resolution services. Third, by using |
2040 |
DOLR abstraction of tightly structured overlay, we can minimize the lack |
DOLR abstraction of tightly structured overlay, we can minimize the lack |
2041 |
of locality in tightly structured overlays. Finally, we believe that issues |
of locality in tightly structured approach. Finally, we believe that issues |
2042 |
related to tightly structured overlays are solved in near future, because of |
related to tightly structured overlays are solved in near future, because of |
2043 |
wide and intensive co-operation among research groups. |
wide and intensive co-operation among research groups. |
2044 |
|
|