1 |
%*********************** |
%*********************** |
2 |
% K?ytet??n gradu2-tyyliluokkaa |
% Käytetään gradu2-tyyliluokkaa |
3 |
%*********************** |
%*********************** |
4 |
\documentclass[a4paper,12pt, english]{gradu2} |
\documentclass[a4paper,12pt, english]{gradu2} |
5 |
|
|
15 |
\usepackage{verbatim} |
\usepackage{verbatim} |
16 |
|
|
17 |
%*********************** |
%*********************** |
18 |
% Tyyliluokan pakolliset m??ritykset |
% Tyyliluokan pakolliset määritykset |
19 |
%*********************** |
%*********************** |
20 |
\title{Fenfire in Peer-to-Peer Environment} |
\title{Fenfire in Peer-to-Peer Environment} |
21 |
|
|
67 |
\begin{document} |
\begin{document} |
68 |
|
|
69 |
%*********************** |
%*********************** |
70 |
% Sis?llysluettelo |
% Sisällysluettelo |
71 |
%*********************** |
%*********************** |
72 |
|
|
73 |
\mainmatter |
\mainmatter |
79 |
\chapter{Introduction} |
\chapter{Introduction} |
80 |
|
|
81 |
Peer-to-Peer systems have recently received considerable attention in both |
Peer-to-Peer systems have recently received considerable attention in both |
82 |
academia and industry for a number of reasons. First, the lack of centralization |
academia \cite{projectirisurl} and industry \cite{p2pworkinggroup}, \cite{jxtaurl} for a |
83 |
|
number of reasons. The lack of centralization |
84 |
means that the participants can form a distributed system without any investment to |
means that the participants can form a distributed system without any investment to |
85 |
centralized, high-priced hardware which would coordinate it. Second, Peer-to-Peer |
centralized hardware which would coordinate it by sharing their services |
86 |
provides new direct way to achieve interoperability between network participants. |
and connecting to each other directly. Additionally, the distributed and ad hoc nature of |
87 |
Finally, the distributed and ad-hoc nature of Peer-to-Peer improves scalability |
Peer-to-Peer improves scalability and avoids single points 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 services |
Working Group defines it as ''the sharing of computer resources and services |
91 |
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} describes Peer-to-Peer systems as |
93 |
properties of Peer-to-Peer network, while most notably the statement |
''The user's machine is a client and a server''. |
94 |
''The user's machine is a client and a server'' describes best Peer-to-Peer |
Schollmeier \cite{schollmeier01p2pdefinition} characterizes a Peer-to-Peer system as a system of |
95 |
systems. Schollmeier \cite{schollmeier01p2pdefinition} characterizes a Peer-to-Peer network as a system of |
distributed entities that share their own services. Thus, Peer-to-Peer systems can be characterized as distributed |
96 |
distributed entities that share their own resources (e.g. CPU time or storage space). |
systems in which all communication is symmetric and all participants entities have similar |
97 |
To summarize, Peer-to-Peer systems can be characterized as distributed |
capabilities and responsibilities. Each entity, i.e., \emph{peer}, may contribute services |
98 |
systems in which all communication is symmetric and all participants entities have identical |
to the overall system. |
99 |
capabilities and responsibilities. Each entity, i.e., \emph{peer}, may contribute data or |
|
100 |
computing resources (e.g., unused storage) to the overall system and the welfare |
In this thesis, we\footnote{Use of the plural is customary even if research |
101 |
of the community can scale with the number of participants. Thus, each participant |
paper is authored solely.} review existing Peer-to-Peer approaches, algorithms and their key properties. |
102 |
rely on one another's services and resources, rather than solely relying on dedicated |
We observe that despite of great amount of proposed Peer-to-Peer systems, all systems fall either to |
|
and centralized infrastructure. |
|
|
|
|
|
One of the most important properties of any distributed computing system are efficient |
|
|
data lookup and security. In this thesis, we\footnote{Use of the plural is customary even if research paper is authored solely.} |
|
|
focus on these aspects in Peer-to-Peer domain. |
|
|
Specifically, we review existing Peer-to-Peer approaches, algorithms and their key properties. We observe |
|
|
that despite of great amount of proposed Peer-to-Peer systems, all systems fall either to |
|
103 |
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 |
104 |
Peer-to-Peer systems and divide problems into three sub-categories: security problems, |
Peer-to-Peer systems and divide problems into three sub-categories: security problems, |
105 |
performance problems and miscellaneous problems. In the end, we summarize all |
performance problems and miscellaneous problems. |
|
problems in easy-to-understand tables. |
|
106 |
|
|
107 |
Next, we give an overview of Fenfire hypermedia system, which implements xanalogical storage model. We |
Next, we give an overview of Fenfire project. Fenfire project is an attempt to build hyperstructured, |
108 |
also describe briefly Storm software module of Fenfire system, which is an essential part of Fenfire's |
seamlessly interoperating desktop environment. Additional features of Fenfire include innovative user |
109 |
Peer-to-Peer functionality. We evaluate existing Peer-to-Peer approaches and |
interfaces for viewing data and usage of Peer-to-Peer networking for network transparency. In Fenfire, |
110 |
choose the best alternative to Fenfire's needs. We discover that Fenfire, xanalogical model and |
all data is stored in the same format, i.e., data blocks. All blocks have globally unique |
111 |
tightly structured Peer-to-Peer approach all have similar method to deal with data, |
identifiers and they can be referred by other blocks, i.e., pointer blocks. |
112 |
i.e., globally unique identifiers. Finally, we propose system model for Fenfire in Peer-to-Peer |
|
113 |
|
After overview, we evaluate existing Peer-to-Peer approaches and |
114 |
|
choose the best alternative to Fenfire's needs. Finally, we propose system model for Fenfire in Peer-to-Peer |
115 |
environment and present yet simple but efficient algorithms to be used for data lookups in |
environment and present yet simple but efficient algorithms to be used for data lookups in |
116 |
Peer-to-Peer environment. |
Peer-to-Peer environment. |
117 |
|
|
118 |
To our knowledge, this thesis is the most comprehensive work with regard to summarizing |
We have attempted to comprehensively summarize existing algorithms and open problems in |
119 |
existing algorithms and open problems in Peer-to-Peer domain. However, this |
Peer-to-Peer domain. However, this thesis is not meant to be detailed work. More detailed |
120 |
thesis is not meant to be detailed work. More detailed information can be found from genuine |
information can be found from references written by original authors. |
|
publications written by original authors. |
|
|
|
|
|
\section{Research problems} |
|
121 |
|
|
122 |
There are three research problems related to this thesis. First research problem |
There are three research problems related to this thesis. First research problem |
123 |
is to find the most efficient way to locate and fetch Fenfire related data from the |
is to find the most efficient way to locate and fetch Fenfire data blocks from the |
124 |
Peer-to-Peer network, where Storm scroll block's identifier is given. Second, we want |
Peer-to-Peer network, where block's identifier is given. Second, we want |
125 |
to find the most efficient way to locate and fetch most recent Fenfire related data from the |
to find the most efficient way to locate and fetch most recent Fenfire data block from the |
126 |
Peer-to-Peer network, which is associated with a given pointer random string. Third problem |
Peer-to-Peer network referred by a pointer block. Third problem |
127 |
is otherwise same as the second problem, except we want to locate and fetch all Fenfire |
is otherwise same as the second problem, except we want to locate and fetch Fenfire |
128 |
related data from the Peer-to-Peer network, where given date and/or time range is given. |
data block from the Peer-to-Peer network, where given date and/or time range is given. |
129 |
|
|
|
\section{Thesis overview} |
|
130 |
This thesis is structured as follows. In next chapter, we give an overview of |
This thesis is structured as follows. In next chapter, we give an overview of |
131 |
existing Peer-to-Peer approaches, algorithms and key differences. In chapter 3, we |
existing Peer-to-Peer approaches, algorithms and key differences between them. In chapter 3, we |
132 |
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 |
133 |
sub-categories. Chapter 4 gives an overview of Fenfire system. In chapter |
sub-categories. Chapter 4 gives an overview of Fenfire system. In chapter |
134 |
5, we evaluate existing Peer-to-Peer approaches with regard to Fenfire system, propose a system |
5, we evaluate existing Peer-to-Peer approaches with regard to Fenfire system. |
135 |
model for Fenfire in Peer-to-Peer environment and present simple algorithms to perform data |
In chapter 6, we present conclusions and future work. |
|
lookups in Peer-to-Peer environment. In addition, we discuss possible problems of using Fenfire |
|
|
in Peer-to-Peer environment. In chapter 6, we present conclusions and future work. |
|
136 |
|
|
137 |
|
|
138 |
\chapter{Peer-to-Peer architectures} |
\chapter{Peer-to-Peer architectures} |
570 |
\endfoot |
\endfoot |
571 |
|
|
572 |
|
|
|
\\ \hline |
|
|
|
|
573 |
\parbox{90pt}{Queries} & |
\parbox{90pt}{Queries} & |
574 |
\parbox{100pt}{Uncontrolled} & |
\parbox{100pt}{Uncontrolled} & |
575 |
\parbox{100pt}{Controlled} |
\parbox{100pt}{Controlled} |
1642 |
|
|
1643 |
\section{Overview} |
\section{Overview} |
1644 |
|
|
1645 |
Fenfire project \cite{fenfireurl} is an effort to build a distributed, hyper structured user |
Fenfire project \cite{fenfireurl} is an effort to build a location transparent, hyperstructured desktop |
1646 |
interface system. Fenfire is free software and it is licensed under GNU L-GPL. Fenfire's main goal |
environment. Fenfire's uses xanalogical storage model \cite{ted-xu-model} as a basis for hyperstructured |
1647 |
is to implement xanalogical storage model \cite{ted-xu-model}. Fenfire was formerly also a implementation |
media. Fenfire uses innovative user interfaces for displaying data to the end users. All data in Fenfire |
1648 |
|
is stored in same format, i.e., blocks. This should allow making references between data easier and more |
1649 |
|
seamlessly interoperating than in other systems. For location transparency in a distributed system, Fenfire |
1650 |
|
uses Peer-to-Peer network for locating and fetching blocks. |
1651 |
|
|
1652 |
|
Fenfire is free software and it is licensed under GNU L-GPL. Fenfire was formerly also a implementation |
1653 |
of the ZigZag\texttrademark --structure, which was originally invented |
of the ZigZag\texttrademark --structure, which was originally invented |
1654 |
by Ted Nelson. Now, however, Fenfire uses Resource Description Framework (RDF) \cite{w3rdfurl} |
by Ted Nelson. Now, however, Fenfire uses Resource Description Framework (RDF) \cite{w3rdfurl} |
1655 |
for representing internal data structures and their relationships. |
for representing internal data structures and their relationships. |
1916 |
are sensitive to certain attacks (e.g., DDoS attack). Additionally, we prefer \emph{abstraction} |
are sensitive to certain attacks (e.g., DDoS attack). Additionally, we prefer \emph{abstraction} |
1917 |
level analysis as very recently better and better tightly structured algorihtms have been proposed. |
level analysis as very recently better and better tightly structured algorihtms have been proposed. |
1918 |
Thus, we don't want to bind our system proposal to a specific algorithm definitively as we expect |
Thus, we don't want to bind our system proposal to a specific algorithm definitively as we expect |
1919 |
that this development continues. |
that this development continues. |
1920 |
|
|
1921 |
In the following subsections we assume that we know the structure of |
In the following subsections we assume that we know the structure of |
1922 |
''virtual file'' before hand, i.e., when assembling a ''virtual file'', we know all Storm |
''virtual file'' before hand, i.e., when assembling a ''virtual file'', we know all Storm |