[Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert...

[Hermanni Hyytiälä]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Hermanni Hyytiälä <address@hidden>      03/03/20 09:47:24

Modified files:
        Documentation/misc/hemppah-progradu: masterthesis.tex 

Log message:
        Lot of updates

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/Documentation/misc/hemppah-progradu/masterthesis.tex.diff?tr1=1.166&tr2=1.167&r1=text&r2=text

Patches:
Index: gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
diff -u gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.166 
gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.167
--- gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.166      Thu Mar 
20 08:07:04 2003
+++ gzz/Documentation/misc/hemppah-progradu/masterthesis.tex    Thu Mar 20 
09:47:24 2003
@@ -860,7 +860,7 @@
 information from multiple entities and trust on the majority's opinion. This 
method requires more messages to be 
 sent to the network while increasing the system load. However, if the Spam 
attack is combined with the Sybil attack, obviously 
 the previously mentioned solution doesn't work. Naor et al. 
\cite{naor03simpledht} have proposed a partial solution against Spam attack
-in \emph{faulty} peer environment (not hostile).
+in a \emph{faulty} peer environment (not hostile).
 
 Traditional overloading of targeted peers is the best known form of 
distributed Denial of Service attack (DDoS) (see, e.g., \cite{372148}). 
 For example, a hostile entity can attempt to burden targeted peers with 
garbage network packets. As an implication, peers may act
@@ -889,8 +889,8 @@
 systems \cite{rivest96sdsi}, \cite{spkiworkinggroup}. PKI is a reliable 
technology for securing
 data in rather \emph{static} computing systems, such as the Internet. However, 
in Peer-to-Peer 
 networks, the problem of key-based security mechanism is the maintenance of 
the keys as participating
-peers constantly join and leave the system. These include revocation of keys 
and new key distribution in hostile 
-environment.
+peers constantly join and leave the system. These include the revocation of 
keys and the distribution of
+new keys in a hostile environment.
 
 ConChord \cite{ajmani02conchord} is the first Peer-to-Peer system which has a 
support for PKI based
 security infrastructure. Still, however, ConChord \cite{ajmani02conchord} is 
in early phase of development and lacks
@@ -899,9 +899,9 @@
 Peer-to-Peer systems, in which hierarchy is intentionally missing.
 
 For data integrity, on the other hand, there are few working solutions. 
Cryptographic content hashes
-\cite{fips-sha-1}, their variations \cite{merkle87hashtree} and implementation 
techniques \cite{mohr02thex},
+\cite{fips-sha-1}, their variations \cite{merkle87hashtree} and implementation 
techniques \cite{mohr02thex}
 are efficient and reliable methods for identifying the integrity of data in 
Peer-to-Peer systems. One
-possible application of cryptographic content hashes may be in peer identifier 
creation process, in which
+possible application of cryptographic content hashes may be in the creation 
process of peer identifier, in which
 the IP address of a peer can be verified by the other peer. This is one form 
of \emph{self-certifying data}. 
 
 
@@ -925,12 +925,12 @@
 Obviously, existance of several types of anonymity often conflicts with other 
key properties of
 Peer-to-Peer systems. Let us consider anonymity and efficient data lookup. In 
efficient data lookup, we must know
 the peers responsible for given data. Of course, when we know the peers 
responsible
-for the data, the anonymity of peer is lost. Fortunately, there are partial 
solutions to previously
-mentioned situations, such as pseudonymity which is a partial form of 
anonymity. For instance, pseudonymity can be used for 
+for the data, the anonymity of peer is lost. Fortunately, there are partial 
solutions to these kinds of
+situations, such as pseudonymity which is a partial form of anonymity. For 
instance, pseudonymity can be used for 
 addressing peer-anonymity by providing anonymous-like identifiers to peers 
(e.g., peer identifiers of a tightly 
 structured system).
 
-Anonymity is widely used in Peer-to-Peer system in which data publication and 
non-censorship are important properties
+Anonymity is widely used in a Peer-to-Peer system in which data publication 
and non-censorship are important properties
 of the system. These include
 Freenet \cite{clarke00freenet}, Publius \cite{pub00}, Free Haven 
\cite{dingledine00free}, Crowds \cite{reiter98crowds},
 Tangler \cite{502002} and upcoming Mnet \cite{mneturl}. Forwarding proxies are 
used in Freenet, Crowds and 
@@ -940,7 +940,7 @@
 of anonymity.
 
 Even if many existing Peer-to-Peer systems are able to provide some of the 
types of anonymity, there is no
-such system which is able to provide all kinds of anonymity as listed above. 
Specifically, the conflicts
+such a system which is able to provide all kinds of anonymity as listed above. 
Specifically, the conflicts
 between anonymity and other Peer-to-Peer system properties require more 
research work.
 
 
@@ -970,36 +970,33 @@
 
 Naturally, centralized authorities could be used for the assignment of peer 
identifiers, but they may not be suitable
 for ad hoc Peer-to-Peer environrment and have property of single point of 
failure. Moreover, distributed peer 
-identification assignment can be problematic as long as Sybil attack 
\cite{douceur02sybil} remains unsolved. 
-However, there are some partial solutions for controlling the rate at which 
hostile entity is able to obtain peer 
+identification assignment can be problematic as long as the Sybil attack 
\cite{douceur02sybil} remains unsolved. 
+However, there are some partial solutions for controlling the \emph{rate} at 
which hostile entity is able to obtain peer 
 identifier, such as crypto-based puzzles \cite{juels99clientpuzzles}.
 
-In the end, none of these problems solutions are able to identify hostile 
entities safely. 
-
-
 \subsection{Secure query routing}
 
 Much work has been done on secure routing, especially related to tightly 
structured systems. In 
-\cite{castro02securitystructured} and \cite{castro02securerouting}, authors 
suggest the usage
-of constrained routing tables and diverse routes, and the detection of faults 
during query routing.
+\cite{castro02securitystructured} and \cite{castro02securerouting}, authors 
suggest the use
+of constrained routing tables and diverse routes, and the detection of faults 
during data lookup routing.
 Additionally, authors present in \cite{castro02securerouting} an important 
aspect of the tightly structured approach with regard
-to fault-tolerant query routing: the probability of routing successfully 
between to arbitrary 
+to fault tolerant query routing: the probability of routing successfully 
between to arbitrary 
 correct peers, when a fraction $f$ of the other peers are faulty or hostile, 
is only $(1-f)^{h-1}$, where
 $h$ is the number of hops in the overlay.
 
-Sit and Morris \cite{sit02securitycons} discuss the possibility of allowing 
query originator 
+Sit and Morris \cite{sit02securitycons} discuss the possibility of allowing 
the query originator 
 to observe lookup progress and cross-check routing tables using random 
queries. However, their
- approach is not very efficient, since proposals create a lot of additional 
network traffic when
+ approach is not very efficient, since this method creates lot of additional 
network traffic when
 in function.
 
-Additionally, Lynch et al. \cite{lynch02atomicdataaccess} propose a solution 
to secure routing table 
+Additionally, Lynch et al. \cite{lynch02atomicdataaccess} propose a solution 
for secure routing table 
 maintenance, but their solution seems to have two major problems 
\cite{castro02securitystructured}. First,
 the solution is very expensive even without faulty or hostile entities. 
Second, each group of replicas
 in their solution must have less than 1/3 of its peers faulty. Thus, this 
feature results in a low
 probability of successful routing.
 
 Aspnes et al. in \cite{aspnes02faultrouting} and Kaashoek et al. in 
\cite{kaashoek03koorde} formally 
-prove the lower and upper bounds for space requirements of locating a specific 
data item in a 
+prove the lower and upper bounds for the space requirements of locating a 
specific data item in a 
 Peer-to-Peer system. They show that to provide high degree of fault tolerance 
and efficiency in the system, each 
 participating peer must maintain average of $O(\log{n})$ neighbors. 
 
@@ -1011,17 +1008,15 @@
 
 Finally, Ratnasamy and Gavoille \cite{ratnasamy02routing, gavoille01routing} 
list several open problems
 regarding routing in distributed networks. Obviously, more research is 
required in order to provide secure
-data lookup routing possible in Peer-to-Peer networks.
+data lookup routing in Peer-to-Peer networks.
 
 
 \subsection{Other security threats}
 
 Ross Lee Graham lists several external threats against Peer-to-Peer networks 
\cite{grahamp2psecurity}. Most important, 
 the list includes viruses and trojans. Currently, there are not even partial 
solutions
-to the problems mentioned above. General robustness properties of a 
Peer-to-Peer system is able to 
-deal with software failures and hostile attacks, but fault tolerance against 
external threats is unknown. 
-The reason for this is that there are no experience on these kinds of attacks. 
Possible solution 
-would be distributed anti-virus software, but much more intensive research is 
required until
+to the problems mentioned above.  The reason for this is that there are no 
experience about these kinds of 
+attacks. Possible solution would be a distributed anti-virus software, but 
much more intensive research is required until
 this kind of solution would be applicable. 
 
 
@@ -1032,20 +1027,19 @@
 \subsection{Efficient data lookup}
 
 The most intensive research in Peer-to-Peer domain has been focused on 
efficient data lookup methods,
-especially with the loosely structured approach. In addition to the 
''super-peer'' method presented in chapter
-2, there has been other improvements also. In iterative deepening 
+especially with the loosely structured approach. In iterative deepening 
 \cite{yang02improvingsearch}, multiple BFS searches are initiated
 with successively larger TTL depth limits, until either the query is 
satisfied, 
-or the maximum depth $D$ has been reached. To perform a data lookup, query
+or the maximum depth $D$ has been reached. To perform a data lookup, the query
 originator starts the data lookup with a small TTL value. If the search is not 
successful,
 the query originator increases the TTL value and performs another data lookup. 
This 
 process is repeated until the desired data is found or the maximum depth $D$ 
 has been reached. Expanding ring, proposed by Shenker et al. in 
\cite{lv02searchreplication}, 
-is similar to iterative deepening technique. With these techniques, search 
-may not be fast when desired data item requires many consecutive flooding 
rounds.
+is similar to the iterative deepening technique. With these techniques, 
searches 
+may not be fast when desired data item requires several consecutive flooding 
rounds.
 
 Directed BFS \cite{yang02improvingsearch} optimizes the original 
-BFS in a way that a peer selects neighbors with many quality results are 
reached in the past, 
+BFS in a way that a peer selects the neighbors which have provided many 
quality results in the past, 
 thereby maintaining the quality of costs and decreasing the amount
 of messages sent to network. Alpine \cite{alpineurl} and NeuroGrid 
\cite{joseph02neurogrid} 
 are Peer-to-Peer systems which use somewhat similar method when performing 
data lookups.
@@ -1053,35 +1047,35 @@
 Local indices \cite{yang02improvingsearch} is a variation of active caching. 
 In this scheme, each peer maintains an index over the data of all peers within 
 $h$ hops of itself, where $h$ is a system-wide variable, called radius of the
-index\footnote{In normal BFS case, the value of $h$ is 0, as peer only has 
index
+index\footnote{In the normal BFS case, the value of $h$ is 0, as a peer only 
has index
 over its local content.}. Mutual index caching architecture, as proposed in 
-\cite{osokine02distnetworks}, is one variation of local indices technique. 
+\cite{osokine02distnetworks}, is a variation of local indices technique. 
 
-In random walk approach \cite{lv02searchreplication}, a peer forwards query to 
a 
+In the random walk approach \cite{lv02searchreplication}, a peer forwards 
query to a 
 randomly selected neighbor. The basic random walk approach
 has a poor response time but it doesn't generate as much network traffic as 
 the original BFS. As suggested in \cite{lv02searchreplication}, the
 random walk approach can be made more effective by introducing
 multiple ''walkers''. Freenet \cite{clarke00freenet} uses 
-random walk searches in query lookups. Indeed, Freenet's query resembles
+random walk searches in data lookups. Freenet's data lookup model resembles
 Depth-First-Search (DFS) and peers' routing tables are dynamically built
 using caching. This is an outcome of Freenet's main design principles, 
anonymity. 
 Another property of the Freenet's data lookup model is that
 it adapts well with varying usage patterns. Improvements to Freenet's data 
lookup using
-the ''small-world phenomenon'' has been proposed by Zhang et al. 
\cite{zhang02using}.
+the ''small-world phenomenon'' have been proposed by Zhang et al. 
\cite{zhang02using}.
 
 Since tightly structured systems have an efficient data lookup at the 
application level overlay,
-current research efforts are focused on a proximity based data lookup. In the 
proximity based data lookup, 
+current research efforts are focused on the proximity-based data lookup. In 
the proximity-based data lookup, 
 peers try to choose entries of routing-tables referring to other peers that 
are \emph{nearby} in the 
 underlying network. In this way, tightly structured systems are able to 
decrease actual 
 lookup \emph{latency}. CAN \cite{ratnasamy01can}, Kademlia 
\cite{maymounkov02kademlia}, 
 Pastry \cite{rowston01pastry} and Tapestry \cite{zhao01tapestry} have advanced 
heuristics for
-the proximity based routing. Additionally, most recent version of Chord uses 
proximity based 
-routing inspired by Karger and Ruhl \cite{karger02findingnearest}. SkipNet 
\cite{harvey03skipnet1} 
+the proximity-based routing. Additionally, most recent version of Chord uses 
proximity-based 
+routing, inspired by Karger and Ruhl \cite{karger02findingnearest}. SkipNet 
\cite{harvey03skipnet1} 
 uses a combination of proximity and application level overlay routing when 
performing data 
 lookups. Authors call this feature as a \emph{constrained load balancing}.
 
-Additional research related to proximity based routing include 
\cite{karger02findingnearest, hildrum02distributedobject, 
+Additional research related to proximity-based routing include 
\cite{karger02findingnearest, hildrum02distributedobject, 
 brinkmann02compactplacement, rhea02probabilistic, castro02networkproximity, 
ng02predicting, pias03lighthouse}.
 
 \subsection{Fast and usable search}
@@ -1091,14 +1085,14 @@
 is the ability to perform keyword searches (e.g., Google \cite{googleurl}). 
Currently, only loosely
 structured systems are able to carry out this requirement. Unfortunately, as 
discussed in this text,
 the data lookup model of the loosely structured approach doesn't scale. Thus, 
research efforts have
-been focused on tightly structured systems. The main problem with tightly 
structured systems is the 
+been focused towards tightly structured systems. The main problem with tightly 
structured systems is the 
 fact that tightly structured algorithms perform data lookups based on a 
globally unique identifier (key). 
 
 Recent study has been focused on the feasibility of Peer-to-Peer Web-like 
indexing and searching 
 on top of tightly structured overlays \cite{li03feasibility} . Authors argue, 
that it is possible to implement 
 Peer-to-Peer Web-like search with certain compromises. First, Peer-to-Peer 
search engine may need to 
 decrease the result quality in order to make searching more efficient. Second, 
Peer-to-Peer systems must 
-observe the properties of underlying network for better performance. 
+consult the properties of underlying network for better performance. 
 
 Some studies have been concentrated on SQL-like queries \cite{harren02complex}
 in tightly structured overlays. Other approaches include adaption of the data 
lookup model of the loosely 
@@ -1118,7 +1112,6 @@
 in \cite{li03feasibility} use Gap compression \cite{wittengigabytes}, Adaptive 
Set Intersection \cite{338634}  
 and clustering with their search optimizations.
 
-
 While it is expected that web-like searches can be layered on a top of tightly 
structured overlay, much
 more research is required to make indexing and searching more efficient.
 
@@ -1137,10 +1130,10 @@
 environments. Furthermore, proposed tightly structured overlays are configured 
statically to achieve 
 the desired reliability even in a uncommon and adverse environment 
\cite{rowston03controlloingreliability}. 
 The most important factor for future research is to get real-life experiences 
from tightly structured 
-systems, when there are frequent joins and leaves in the system. Some research 
has been done already in this area. 
+systems, when there are frequent joins and leaves in the system.
 
-A concept of ''half-life'' was introduced by Liben-Nowell 
\cite{libennowell01observations} since Peer-to-Peer 
-system is \emph{never} in the ''ideal'' state as it is continiously evolving 
system. Half-life is defined
+The concept of ''half-life'' was introduced by Liben-Nowell 
\cite{libennowell01observations} since Peer-to-Peer 
+system is \emph{never} in the ''ideal'' state as Peer-to-Peer system is 
continiously evolving system. Half-life is defined
 as follows: let there be $N$ live peers at time $t$. The doubling from time 
$t$ is the time that pass before
 $N$ new additional peers arrive into the system. The halving time from time 
$t$ is the time
 required for half of the living peers at time $t$ to leave the system. The 
half-life from 
@@ -1166,22 +1159,22 @@
 a serious problem of tightly structured overlays in face of performance and 
load balancing. Measurement study 
 by Saroiu et al. show that there is a extreme heterogeneity among 
participating peers in already deployed Peer-to-Peer 
 systems \cite{saroiu02measurementstudyp2p}. Symphony \cite{gurmeet03symphony} 
seems to be the first tightly structured overlay system 
-which supports heterogeneity. Zhao et al. have proposed a secondary layer on 
top of structured overlay
+which supports heterogeneity. Zhao et al. have proposed a secondary layer on 
top of a structured overlay
 to support heterogeneity better \cite{zhao02brocade}. 
 
 Research has been done on self-organization. Ledlie et al. propose techniques 
for forming and maintaining
-groups in highly dynamic environment \cite{ledlie02selfp2p}. Unfortunately 
their work relies on the idea that
+groups in a highly dynamic environment \cite{ledlie02selfp2p}. Unfortunately 
their work relies on the idea that
 participating peers would create multiple hierarchical groups. It is not clear 
whether this approach
-is fault tolerant and suitable for a Peer-to-Peer environment. More promising 
work has been done by Rowston et al.
+is fault tolerant and suitable for Peer-to-Peer environment. More promising 
work has been done by Rowston et al.
 in \cite{rowston03controlloingreliability}. Authors propose techniques for 
self-tuning, dealing with
 uncommon conditions (e.g., network partition and high failure rates). 
Moreover, authors argue that
 with these techniques, the concerns over tightly structured overlay 
maintenance costs are no more
 an open issue.
 
 Finally, little research has been done regarding self-monitoring and data 
availability. Zhang et al.
-describe an arbitrary data structure on top of a tightly structured overlay 
\cite{zhang03somo}. They
-call their proposal as a \emph{data overlay}, since it supports several 
fundamental data structures.
-Authors use this data overlay to build Self-Organized Meta data Overlay 
(SOMO), which can be used
+describe an arbitrary data structure on top of a tightly structured overlay 
\cite{zhang03somo}. Authors
+call their technique as a \emph{data overlay}, since it supports several 
fundamental data structures.
+Authors have used this data overlay when building a Self-Organized Meta data 
Overlay (SOMO), which can be used
 for monitoring the health of a tightly structured overlay. The fault tolerance 
of SOMO itself is currently
 unknown. 
 
@@ -1195,15 +1188,15 @@
 All existing Peer-to-Peer systems have rather different interfaces even though 
they have common properties and 
 components. More important, all existing Peer-to-Peer systems are incompatible 
with each other. One
 of the most important area of future research is to create common programming 
abstractions, i.e.,
-interfaces, design patters and frameworks. Also, equal benchmarks are needed 
for comparing
-different algorithms. Recently, there have been few proposals towards common 
programming
+interfaces, design patters and frameworks. Also, benchmarks are needed for 
comparing
+different algorithms equally. Recently, there have been few proposals towards 
common programming
 guidelines. This list includes \cite{zhao03api, frise02p2pframework, 
babaoglu02anthill}.
 Early experiments with Peer-to-Peer benchmarking include 
\cite{ratnasamy02routing, rhea03benchmarks}.
 
 \subsection{Social behavior}
 
 Frequent assumption in Peer-to-Peer systems is that peers are willing to 
cooperate. Another belief 
-is that all peers would behave equally, i.e., all peers both consume and 
contribute resources.
+is that all peers would behave equally, i.e., all peers both consume and 
contribute services.
 However, these assumptions are not true as several studies show 
\cite{saroiu02measurementstudyp2p, 
 oram01harnessingpower, hearn02mojonation}. Peers rather consume than 
contribute and peers are 
 unwilling to cooperate. 
@@ -1224,13 +1217,13 @@
 
 Very little research has been done on simulating a Peer-to-Peer system. 
Presumably, this
 is due to complex nature of Peer-to-Peer system, which makes comprehensive 
simulations very 
-difficult. Floyd et al. has been studying the simulation of the Internet in 
\cite{504642}. Authors
+difficult. Floyd et al. have been studying the simulation of the Internet in 
\cite{504642}. Authors
 state that simulating the Internet is very challenging task, because of its 
heterogeneity
 and rapid change. Obviously, these factors exist also in Peer-to-Peer systems 
even with higher
 rates.
 
 As long as comprehensive simulations of a Peer-to-Peer systems are lacking, we 
cannot make any detailed
-analysis on general properties of Peer-to-Peer system such as usage patterns. 
However, we can assume 
+analysis on general properties of a Peer-to-Peer system, such as usage 
patterns. However, we can assume 
 that, e.g., query keywords follow the Zipf-like distribution 
\cite{breslau98implications} both in the 
 Internet and in Peer-to-Peer systems.
 
@@ -1559,7 +1552,7 @@
 \parbox{90pt}{Locating Peer-to-Peer network} &
 \parbox{110pt}{How old peers or new peers are able to locate Peer-to-Peer 
network, if it exists} &
 \parbox{110pt}{Servers maintaining online peers (e.g. gnutellahosts.com), 
peer's history information} &
-\parbox{110pt}{Depends on implementation and purpose of the system, for 
desktop based 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, for mobile ad hoc networks more 
research is needed (Mobile ad hoc 
 networks (MANETs) can be only connected through radio resource interface, 
i.e., peers which are in same geographical area)}
 \\ \hline
 
@@ -1582,12 +1575,12 @@
 The Fenfire project \cite{fenfireurl} is an effort to build a location 
transparent, hyperstructured desktop 
 environment. Fenfire uses xanalogical storage model \cite{ted-xu-model} as a 
basis for hyperstructured
 media. Fenfire deploys innovative user interfaces for displaying data to the 
end users. All data in the Fenfire
-is stored in a unified format, blocks. This should allow making references 
between data easier and more 
-seamlessly interoperating than in other systems. For location transparency in 
a distributed system, Fenfire 
+is stored in a unified format, i.e., blocks. This features should allow making 
references between \emph{any} 
+data easier and more seamlessly interoperating than in other systems. For 
location transparency in a distributed system, Fenfire 
 uses Peer-to-Peer network for locating and fetching blocks.
 
 Fenfire is a free software and it is licensed under GNU LGPL.  Fenfire was 
formerly also a partial implementation 
-of the ZigZag\texttrademark --structure, which was originally invented 
+of the ZigZag\texttrademark -- structure, which has been originally invented 
 by Ted Nelson. Now, however, Fenfire uses Resource Description Framework (RDF) 
\cite{w3rdfurl}
 for representing internal data structures and their relationships. 
 
@@ -1595,18 +1588,19 @@
 
 \begin{itemize}
 \item \textbf{Storm}: a distributed storage module for storing arbitrary data 
items
-\item \textbf{Navidoc}: an UML based tool for generating software 
documentation  
+\item \textbf{Navidoc}: an UML-based tool for generating software 
documentation  
 \item \textbf{Alph}: a xanalogical hypertext built upon Storm storage model
 \item \textbf{GLMosaicText}: a flexible OpenGL interface for font manipulation
 \item \textbf{CallGL}: a wrapping library used for OpenGL calls
 \item \textbf{LibVob}: a graphic library used for creating navigation 
interfaces in complex data views
 \end{itemize}
 
-In this thesis, we focus on Storm and Alph modules, since they are the 
foundation of Fenfire's 
-Peer-to-Peer functionality. If not otherwise mentioned, we use term 'Storm' 
when referring to both
-Storm and Alph software modules. For location transparency in the Fenfire 
system, Storm software module 
+
+For location transparency in the Fenfire system, Storm software module 
 must have a support for Peer-to-Peer functionality as it provides low-level 
data storage operations
-in the Fenfire system.
+in the Fenfire system. Therefore, we focus on Storm and Alph modules, since 
they are the foundation of Fenfire's 
+Peer-to-Peer functionality. If not otherwise mentioned, we use term 'Storm' 
when referring to both
+Storm and Alph software modules. 
 
 
 \section{Xanalogical storage model}
@@ -1618,24 +1612,24 @@
 permanent, globally unique identifier. For instance, let's consider the 
following
 scenario: ''the character 'D' typed by Janne Kujala on 10/8/97 8:37:18''. In 
this
 example, when character 'D' is first typed in, xanalogical storage model
-acquires a permanent identifier for that character and retains it when 
character
+acquires a permanent identifier for that character and retains it when the 
character
 is copied to different document. Thus, the identifier distinguishes the 
character from 
 all similar characters typed in independently\footnote{Xanalogical storage 
model
 is not limited to text. It can support arbitrary data, e.g., pixels of picture 
or 
-frames of video.}. The connectivity in the xanalogical storage model between 
data content 
+frames of video.}. The connectivity in xanalogical storage model between data 
content 
 is more substantial than in other models; a link is shown between any two data 
contents 
 containing a specific \emph{fluid media unit} (e.g., a character) that the 
link connects.
 In practice, however, xanalogical storage model uses \emph{spans}, ranges of 
consecutive
 fluid media units to perform storage operations. This is done for better 
performance as
-doing expensive operations for every fluid media unit is not efficient. As a 
implication,
-the xanalogical storage model stores fluid media units to append-only 
\emph{scrolls}.
+doing expensive operations for every fluid media unit is not efficient. 
Xanalogical 
+storage model stores fluid media units to append-only \emph{scrolls}.
 
-\emph{Enfilade} can be considered as a ''virtual file'' (or part of one), 
which is a list
-of fluid media content. In the xanalogical storage model, links between 
content are external 
+An \emph{enfilade} can be considered as a ''virtual file'' (or part of one), 
which is a list
+of fluid media content. In xanalogical storage model, links between content 
are external 
 and bidirectional. Xanalogical link is an \emph{association} of two enfilades, 
such as an 
 annotation to a specific part of a another document. \emph{Transclusion} is an 
inclusion in 
 enfilade of contents already used in another enfilade, i.e., current fluid 
media is copied into 
-different data contents. By using this mechanism, a system implementing the 
xanalogical storage model
+different data content. By using this mechanism, a system implementing 
xanalogical storage model
 is able to show all data content that share the same fluid media with current 
data content
 (e.g., all documents containing current document's text). Figure 
\ref{fig:xanalogical_model}
 illustrates xanalogical storage model with documents, text and characters.
@@ -1664,8 +1658,8 @@
 SHA-1 \cite{fips-sha-1} is used for verifying the integrity of Storm data 
blocks. Storm
 blocks have much in common with regular files, except that Storm blocks are 
\emph{immutable} as
 any change to the byte sequence would change block's hash value (globally 
unique 
-identifier). This mechanism creates a basis for implementing xanalogical 
storage model in 
-in Fenfire system. Figure \ref{fig:storm_model} illustrates simplified Storm 
storage model.
+identifier). This mechanism creates a basis for implementing xanalogical 
storage model 
+in the Fenfire system. Figure \ref{fig:storm_model} illustrates simplified 
Storm storage model.
 
 \begin{figure}
 \centering
@@ -1686,7 +1680,7 @@
 (URN) \cite{rfc2396}. Pointer itself doesn't contain any data, it is rather a 
\emph{concept} of
 data. Pointers are created automatically by Storm and each pointer is 
 associated with a collection of \emph{pointer blocks}. Pointer block has a 
single 
-target for the pointer. In figure \ref{fig:storm_model}, we present the 
overall 
+target for the pointer. In figure \ref{fig:storm_model}, we show the overall 
 pointer creation process. Pointer block may contain zero or more obsoleted 
 pointer blocks, i.e., when a new version of scroll block is created, it 
supersedes 
 one older version which has been created in the past. The most current pointer 
@@ -1704,53 +1698,53 @@
 
 \chapter{Evaluation of Peer-to-Peer for Fenfire}
 
-In this chapter we evaluate Fenfire in a Peer-to-Peer environment.
-We start by giving a problem overview when considering Fenfire in a 
Peer-to-Peer
+In this chapter we evaluate Fenfire in Peer-to-Peer environment.
+We start by giving a problem overview when considering Fenfire in Peer-to-Peer
 environment. We define Fenfire's special needs and evaluate existing 
 Peer-to-Peer approaches in light of these requirements. After that, we propose 
a system
 model for Fenfire and present simple methods to perform data 
-lookups in a Peer-to-Peer environment. In the end of this chapter, we discuss 
possible problems of using Fenfire
-in a Peer-to-Peer environment.
+lookups in Peer-to-Peer environment. In the end of this chapter, we discuss 
possible problems of using Fenfire
+in Peer-to-Peer environment.
 
 
 \section{Problem overview}
 
-As already mentioned in chapter 4, a xanalogical document is a ''virtual
+As already mentioned in chapter 4, xanalogical document is a ''virtual
 file'', in which parts of the document are fetched from a 
-\emph{global} data repository. Thus, system implementing the xanalogical 
storage model \emph{must}
+\emph{global} data repository. Thus, system implementing xanalogical storage 
model \emph{must}
 support global data lookups efficiently in order to assemble the ''virtual 
file''
 from fragments of data. 
 
-In the xanalogical storage model, each fragment of data is identified by a 
globally 
+In xanalogical storage model, each fragment of data is identified by a 
globally 
 unique identifier. In the Fenfire system, data fragments are scroll blocks 
generated by Storm storage module.
 As we discussed already in chapter 4, Fenfire's Storm design 
 uses SHA-1 \cite{fips-sha-1} hash over the contents of a scroll block for 
creating globally unique 
 identifiers for each scroll block.  In our scenario, fragments of data is 
distributed 
-throughout the Peer-to-Peer overlay. We want that user operations in Fenfire 
are location transparent.
+throughout the Peer-to-Peer overlay network. We want that user operations in 
Fenfire are location transparent.
 Therefore, our task is to locate and fetch (i.e. obtain) \emph{all} Storm 
scroll blocks, associated to a specific ''virtual 
 file'' from the Peer-to-Peer overlay as efficiently as possible. In addition 
to the
 \emph{direct} scroll block obtaining using globally unique identifier of Storm 
scroll block, 
-we also must support the \emph{indirect} obtaining of Storm scroll block using 
pointer blocks.
+we also must support the \emph{indirect} obtaining of Storm scroll block using 
the pointer blocks.
 
-Obviously, our objectives are simple but yet hard to fulfill. First, as a 
prerequisite
-to implementing xanalogical storage model in a Peer-to-Peer environment, a 
system
+Our objectives are simple but yet hard to fulfill. First, as a prerequisite
+to implementing xanalogical storage model in Peer-to-Peer environment, a system
 supporting data lookups must be able to perform \emph{global} scale lookups. 
Thus, 
-we must be able to locate and fetch Storm block, if it exists in the 
+we must be able to obtain the Storm block, if it exists in the 
 Peer-to-Peer overlay. Second, data lookups have to be efficient, since 
constructing 
 one ''virtual file'' may need obtaining several Storm blocks, which are 
distributed 
 randomly throughout the overlay; if not efficient, construction of the 
''virtual file''
 may take reasonable amount of time while rendering system very unusable. 
Third, Peer-to-Peer 
-infrastructure has to be scalable and robust against hostile attacks.
+infrastructure has to be scalable and fault tolerant against hostile attacks.
 
-Some research regarding to these problem has been made by Lukka et al. 
-\cite{lukka02freenetguids}. Authors' work is mainly based on the insight of 
implementing the 
-xanalogical storage model in a Peer-to-Peer environment with globally unique 
identifiers. Lukka et al.
+Some research regarding to these problems have been made by Lukka et al. 
+\cite{lukka02freenetguids}. Authors' work is mainly based on the insight of 
implementing  
+xanalogical storage model in Peer-to-Peer environment with globally unique 
identifiers. Lukka et al.
 use Freenet \cite{clarke00freenet} as an example Peer-to-Peer system 
supporting 
 globally unique identifiers. The work presented in this thesis extends their 
work by 
 evaluating different Peer-to-Peer systems more extensively to Fenfire's needs.
  
 Additionally, related to non-xanalogical hypermedia systems, Bouving 
-\cite{bouvin02openhypermedia} has done initial work regarding  ways in which 
+\cite{bouvin02openhypermedia} has done initial work regarding ways in which 
 Peer-to-Peer can be used in non-xanalogical hypermedia systems. Thompson and 
de Roure 
 \cite{thompson01hypermedia} have studied locating documents and links in 
Peer-to-Peer
 environment. At the Hypertext '02 panel, moderated by Wiil 
\cite{wiil02p2phypertext},
@@ -1759,35 +1753,35 @@
 
 \section{Evaluation of Peer-to-Peer approaches with regard to Fenfire}
 
-In chapter 2, we discussed main differences between loosely and tightly 
structured 
-approaches. As stated, the most significant difference is that the tightly 
structured 
+In chapter 2, we discussed main differences between the loosely and the 
tightly structured 
+approach. As stated, the most significant difference is that the tightly 
structured 
 approach has logarithmical properties in all internal operations, while the 
loosely 
 structured approach doesn't always have even linear properties. Furthermore, 
the
-data lookup model of tightly structured overlay scales much better than 
loosely 
-structured overlays; tightly structured overlay supports global data lookups
+data lookup model of the tightly structured overlay scales much better than in 
loosely 
+structured overlays; the tightly structured overlay supports global data 
lookups
 in the overlay, whereas the data lookup model of the loosely structured 
approach
-is limited to certain area of the overlay\footnote{The area depends on where 
the query
+is limited to a certain area of the overlay\footnote{The area depends on where 
the query
 originator is located in the overlay.}.
 
-For Fenfire's special needs for \emph{locating} data, an important advantage 
of the 
+For Fenfire's needs for \emph{locating} data, an important advantage of the 
 tightly structured approach over the loosely structured approach is that 
tightly 
 structured systems use location-independent, globally unique identifiers for 
 identifying data in the system. Indeed, this 
-feature is almost analogical to Fenfire's (and xanalogical storage model's) 
way of 
+feature is similar to Fenfire's (and xanalogical storage model's) way of 
 handling data. Another key feature of tightly structured overlays is that they 
are able
 to provide general purpose \emph{interface} for Reference Resolution Services 
(RRS)\footnote{
 Domain Name System (DNS) \cite{rfc1101} is a widely used RRS system in the 
Internet.}
  \cite{balakrishnan03semanticfree}. Authors argue that next generation RRS 
must be 
 application-independent and references itself should be \emph{unstructured} 
and 
-\emph{semantically free}. Finally, as said, with tightly structured systems, 
it is feasible to 
+\emph{semantically free}. Finally, as said, with tightly structured systems it 
is feasible to 
 perform \emph{global} data lookups in the overlay. To summarize, these aspects 
may be the most important features 
 of Peer-to-Peer infrastructure with regard to Fenfire as a distributed, 
location transparent hypermedia system.
-Thus, we see the tightly structured approach as the best alternative to locate 
data in a Peer-to-Peer
+Thus, we see the tightly structured approach as the best alternative to locate 
data in Peer-to-Peer
 environment.
 
 Once located, we can use regular TCP/IP-protocols, such as Hypertext Transfer 
protocol (HTTP) 
 \cite{rfc2068} for \emph{fetching} Storm blocks from the overlay. However, 
HTTP-protocol may 
-not be optimal when obtaining large amounts of data from a Peer-to-Peer 
network (e.g., 
+not be a optimal solution when obtaining large amounts of data from a 
Peer-to-Peer network (e.g., 
 videos, images or music). In this case, multisource downloads can be very 
useful 
 for better efficiency \cite{maymounkov03ratelesscodes, bittorrenturl}. 
Furthermore, 
 multisource downloads can be used for decreasing load of a certain peer, thus 
avoiding query 
@@ -1795,7 +1789,7 @@
 standard single source downloads (HTTP) and SHA-1 \cite{fips-sha-1} 
cryptographic content 
 hash for verifying the integrity of data by recomputing the content hash
 for a scroll block. In face of multisource downloads, Fenfire must support
-tree-based hashes\footnote{With multisource downloads, tree based hash 
functions can be used 
+tree-based hashes\footnote{With multisource downloads, tree-based hash 
functions can be used 
 to verify fixed length segments of data. If hash value of data segment is 
incorrect, 
 we need only to fetch \emph{segment} of data (instead of whole data) from 
 an other source.}, such as \cite{merkle87hashtree, mohr02thex} for reliable 
and efficient 
@@ -1808,15 +1802,15 @@
 Additionally, there is only little real world experiments yet with tightly 
structured systems
 (e.g., \cite{overneturl, edonkey2kurl}). Therefore, we can't say for sure, how 
well these 
 systems would perform in real Peer-to-Peer environment. However, we believe 
that these issues are 
-solved, since there is a strong and wide research community towards to tightly 
structured 
+solved, since there is a strong and wide research community towards to the 
tightly structured 
 overlays \cite{projectirisurl}.
 
       
 \section{Fenfire system model in Peer-to-Peer environment}
 
 In this section we give a proposal for Fenfire Peer-to-Peer system, which 
consists 
-of several technologies reviewed in this thesis.  Then, we introduce simple 
but 
-yet effective methods for obtaining Fenfire data from a Peer-to-Peer 
environment. 
+of several technologies reviewed in this thesis.  Then, we introduce methods 
for 
+obtaining Fenfire data from a Peer-to-Peer network. 
  
 \subsection{System proposal}
 
@@ -1833,16 +1827,16 @@
 locate nearby data without looking up data from distant peers. Moreover, 
authors' 
 proposal for self-organizing clusters using network diameters may be useful, 
 especially within small groups of working people. Thus, with Sloppy hashing
-we can provide locality properties for Fenfire.
+we can provide locality properties for the Fenfire system.
 
 For better fault tolerance and self-monitoring for Fenfire, we propose 
techniques
 presented by Rowston et al. \cite{rowston03controlloingreliability}.  With 
these 
-techniques, we can ensure the performance of Fenfire in a highly adverse 
conditions, such
+techniques, we can ensure the performance of the Fenfire system in a highly 
adverse conditions, such
 as sudden network partition, or highly dynamic and heterogeneous environment.
 
 Finally, for more efficient data transfer, we can use variable techniques for 
this purpose.
 For small amounts of data, HTTP can be used \cite{rfc2068}. For big amounts of 
data, we can use
-multisource downloads for better efficiency and reliability. Specifically, 
technology based
+multisource downloads for better efficiency and reliability. Specifically, the 
technology based
 on rateless erasure codes \cite{maymounkov03ratelesscodes} seems very 
promising.
 
 \subsection{Methods}
@@ -1850,50 +1844,50 @@
 We use the DOLR abstraction of the tightly structured approach, i.e., each 
participating peer hosts 
 the data and the overlay maintains only the \emph{pointers} to the data. We 
decided to use the DOLR 
 abstraction in our model, since DOLR systems locate data without specifying a 
storage policy explicitly \cite{rhea03benchmarks}. 
-DHT based storage systems, such as CFS \cite{dabek01widearea} and PAST 
\cite{rowstron01storage}, may have
-critical problems with load balancing in a highly heterogeneous environment. 
This problem is caused by peers 
-which may not be able to store relatively large amount of data with key-value 
pair, assigned randomly by 
+DHT-based storage systems, such as CFS \cite{dabek01widearea} and PAST 
\cite{rowstron01storage}, may have
+severe problems with load balancing in a highly heterogeneous environment. The 
problem is caused by peers 
+which may not be able to store relatively large amount of data with a 
key-value pair, assigned randomly by 
 the mapping function of the overlay. These systems waste both storage and 
bandwidth, and
-are sensitive to certain attacks (e.g., DDoS attack). Additionally, we 
emphasize that we prefer \emph{abstraction}
+are sensitive to certain attacks (e.g., the DDoS attack). Additionally, we 
emphasize that we prefer \emph{abstraction}
 level analysis as very recently better and better tightly structured 
algorithms have been proposed. 
 Thus, we don't want to bind our system proposal to a specific algorithm 
definitively as we expect 
-that this development continues.
+that this development continues. In this model, we use Kademlia's 
\cite{maymounkov02kademlia} algorithm for 
+locating data in the overlay.
 
 In the following subsections we assume that we know the structure of 
-the ''virtual file'' before hand, i.e., when assembling the ''virtual file'', 
we know all Storm 
-blocks, which are required when building the ''virtual file''. Also, we don't 
-respond to security issues related to Peer-to-Peer systems, since there is no 
working solution
+the enfilade before hand, i.e., when assembling the ''virtual file'' we know 
all the Storm 
+blocks, which are required to complete the enfilade. Also, we don't 
+respond to the security issues related to Peer-to-Peer systems, since there is 
no working solution
 available yet; we either assume that Fenfire has a reliable technique for 
identifying individual entities, or
 there are no hostile entities among participating peers. 
 
-In our model, each peer maintains following data structures for local 
operations: a data structure for listing all 
+In our method, each peer maintains the following data structures for local 
operations: a data structure for listing all 
 key-value pairs which peer maintains; a data structure for listing all 
key-value pairs in the 
 chronological order (the most recent block is topmost) which peer maintains. 
We use Storm blocks' identifiers
 as \emph{keys} of the overlay. Every key-value pair consists of either a hash 
of pointer random string 
-(pointer blocks), or a hash of block's content (scroll blocks) as a key. Value 
is always a reference to a hosting 
-peer (e.g., IP address). We use Kademlia's \cite{maymounkov02kademlia} 
algorithm for locating data in the overlay. 
-Finally, we assume that all local operations can be done in a constant time.
+(pointer blocks), or a hash of block's content (scroll blocks) as a key. The 
value is always a reference to a hosting 
+peer (e.g., IP address). Finally, we assume that all local operations can be 
done in a constant time.
 
 
 \begin{itemize}
 \item Data lookup with a given identifier of Storm scroll block.
 \begin{enumerate}
-\item Submit data lookup using scroll block's identifier.
+\item Submit the data lookup using scroll block's identifier.
 \item Repeat until the pointer peer is found: each peer forwards the data 
lookup to a closer peer which hosts the given scroll block identifier.
 \item The pointer peer returns value (e.g., the IP address of provider peer) 
to the query originator.
 \item The query originator requests the provider peer to return the scroll 
block.
 \end{enumerate}
 \end{itemize}
 
-Figure \ref{fig:storm_query_blockid} illustrates how a Storm scroll block is 
located 
-in tightly structured overlay using the DOLR abstraction, where the identifier 
of Storm scroll 
-block is known.
+Figure \ref{fig:storm_query_blockid} illustrates how Storm scroll block is 
located 
+in a tightly structured overlay using the DOLR abstraction, where the 
identifier of Storm scroll 
+block is given.
 
 
 \begin{itemize}
 \item Data lookup with a given pointer random string returning most recent 
scroll block.
 \begin{enumerate}
-\item The query originator locally computes a hash for given pointer random 
string.
+\item The query originator locally computes a hash over given pointer random 
string.
 \item Repeat until the pointer peer is found: each peer forwards the data 
lookup to a closer peer which hosts the given hash of pointer random string.
 \item The pointer peer returns most recent pointer block's key-value pair 
(e.g., the IP address of provider peer) to the query originator, using pointer 
block's own indexing schemes. 
 \item The query originator requests the provider peer to return the scroll 
block.
@@ -1903,7 +1897,7 @@
 \begin{itemize}
 \item Data lookup with a given pointer random string returning scroll block(s) 
for a given date or time range.
 \begin{enumerate}
-\item The query originator locally computes a hash for given pointer random 
string.
+\item The query originator locally computes a hash over given pointer random 
string.
 \item Repeat until the pointer peer is found: each peer forwards the data 
lookup to a closer peer which hosts the given hash of pointer random string.
 \item Pointer peer returns pointer block's key-value pair(s) (e.g., the IP 
address of provider peer) to the query originator, using pointer block's own 
indexing schemes. 
 \item The query originator requests the provider peer to return the scroll 
block.
@@ -1911,9 +1905,9 @@
 \end{itemize}
 
 Figure \ref{fig:storm_query_urn5} illustrates how Storm scroll block is 
located 
-in tightly structured overlay using the DOLR abstraction, where the pointer 
random string is known.
+in a tightly structured overlay using the DOLR abstraction, where the pointer 
random string is given.
 
-Each of these algorithms can locate Fenfire data in $O(\log{n})$ time at 
application level overlay:
+Each of these algorithms can locate Fenfire blocks in $O(\log{n})$ time at 
application level overlay:
 $O(\log{n})$ time for query routing to pointer peer and constant time for 
 locating hosting peer with a given reference link.
 
@@ -1935,12 +1929,12 @@
 
 \subsection{Problems}
 
-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 the non-maturity of
 security technologies. For instance, online entities cannot be identified 
-safely (e.g., the Sybil attack \cite{douceur02sybil}). For Fenfire, one
-security related problem occurs when user wants to perform a global data 
lookup with a given
-pointer random string; how can a user verify the correctness
-of the search results ? Specifically, how she or he knows which one is the 
+safely (e.g., the Sybil attack \cite{douceur02sybil}). For the Fenfire system, 
one
+security related problem occurs when a user wants to perform a global data 
lookup with a given
+pointer random string; how the user is able to verify the correctness
+of the search results, i.e.,  how she or he knows which one is the 
 correct Storm scroll block ? The Spam attack \cite{naor03simpledht} is a 
variation of previously
 mentioned problem; data lookup is performed by a user, but there is no reply
 from the system. How are we able to know if this was a spam attack, or the
@@ -1950,7 +1944,7 @@
 authenticity of data. Obviously, optimal solution to all security issues would 
 be that digital signatures are included to every message sent to the system 
therefore 
 enabling peers to authenticate other peers safely. However, these problems are 
not 
-only limited to the Fenfire as it concerns all Peer-to-Peer based computer 
systems.
+only limited to the Fenfire system as it concerns all Peer-to-Peer computer 
systems.
 
 As security technologies come more mature, we wish to apply these 
 technologies with Fenfire, if applicable.
@@ -1958,38 +1952,35 @@
 \chapter{Conclusions and future work}
 
 In this thesis, we have reviewed existing Peer-to-Peer approaches, algorithms 
and
-their properties.  We have summarized open problems in Peer-to-Peer research 
domain. 
-Specifically, we divided open problems into the three sub-categories: security 
related problems,
-performance related problems and miscellaneous problems. Each of these
+their properties. Our insight is that despite the great amount of Peer-to-Peer 
systems, 
+we are able to classify \emph{all} systems either to loosely or tightly 
structured systems.  
+We have summarized open problems in Peer-to-Peer research domain. 
Specifically, we divided open 
+problems into the three sub-categories: security related problems,
+performance related problems and miscellaneous problems.  We point out that 
each of these
 sub-categories have number of open problems, in which there are no solutions
-yet, or solutions are only partial. We point out that much research work is 
required to
-solve these problems.
+yet, or solutions are only partial. 
 
 Then, we focused our attention to the Fenfire system. First, we gave a brief
-overview of Fenfire and xanalogical storage model. We also described Storm 
software module.
+overview of the Fenfire system and xanalogical storage model. We also 
described Storm software module.
 
 In the last chapter, we evaluated existing Peer-to-Peer approaches with regard
-to Fenfire's needs. We proposed that the tightly structured approach is the
+to Fenfire's needs. We see that the tightly structured approach is the
 best alternative to Fenfire's needs for the following reasons. First, Storm, 
xanalogical
 storage model and tightly structured systems use global unique identifiers
 for identifying data. Second, our Storm design uses \emph{semantic-free 
references} 
 (block identifiers and pointer random strings) for locating data in 
distributed 
 networks. As the authors of \cite{balakrishnan03semanticfree},
-we also agree that references should be semantically-free in the 
next-generation 
+we also agree that references should be semantically-free in next-generation 
 reference resolution services. Third, by using 
 the DOLR abstraction of tightly structured overlay, we can minimize the lack 
 of locality in the tightly structured approach. Finally, we believe that 
issues 
 related to tightly structured overlays are solved in the near future, because 
of
 wide and intensive co-operation among research groups.
 
-Then, we proposed system model for Fenfire and presented simple methods to 
perform data 
-lookups in a Peer-to-Peer environment.
-
-Our future work includes support for searching transclusions and xanalogical
-links in a Peer-to-Peer network. Specifically, we want to find transclusions
-and xanalogical links in a global scale. Preliminary analysis have shown
+Our future work includes a support for searching transclusions and xanalogical
+links in Peer-to-Peer environment. Preliminary analysis have shown
 that these questions are rather different than locating scroll or pointer
-blocks \emph{directly} from the network. Techniques used in distributed 
+blocks from Peer-to-Peer environment. Techniques used in distributed 
 database systems may prove to be useful. Some fundamental results
 regarding Peer-to-Peer and database systems have already been
 presented in \cite{gribble01p2pdatabase}.