[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/18 09:12:51

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

Log message:
        More updates and corrections

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

Patches:
Index: gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
diff -u gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.153 
gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.154
--- gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.153      Mon Mar 
17 10:07:39 2003
+++ gzz/Documentation/misc/hemppah-progradu/masterthesis.tex    Tue Mar 18 
09:12:50 2003
@@ -1008,7 +1008,7 @@
 
 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 detection of faults 
during query routing.
+of constrained routing tables and diverse routes, and the detection of faults 
during query 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 
 correct peers, when a fraction $f$ of the other peers are faulty or hostile, 
is only $(1-f)^{h-1}$, where
@@ -1022,18 +1022,18 @@
 Additionally, Lynch et al. \cite{lynch02atomicdataaccess} propose a solution 
to 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 peer faulty. Thus, this 
feature results in a low
+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 
-Peer-to-Peer system. They show that to provide high degree of fault tolerance 
and efficiency, each 
+prove the lower and upper bounds for 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. 
 
 Fiat et al. in \cite{fiat02censorship, saia02dynamicfaultcontentnetwork} and 
Datar in \cite{datar02butterflies}  
-describe tightly structured overlay with analytical results in the presence of 
hostile entities. However,
-none of these proposals address an efficient, dynamic tightly structured 
overlay and multiple rounds
-of hostile attack. Also, above mentioned proposals are not very efficient. In 
\cite{fiat02censorship}, each peer 
+describe a tightly structured overlay with analytical results in the presence 
of hostile entities. However,
+none of these proposals address a dynamic tightly structured overlay with 
fault tolerance against multiple rounds
+of hostile attacks. Also, above mentioned proposals are not very efficient. In 
\cite{fiat02censorship}, each peer 
 must maintain information of $O(\log^3{n})$ other peers, and in 
\cite{datar02butterflies}, $O(\log^2{n})$ is required.
 
 Finally, Ratnasamy and Gavoille \cite{ratnasamy02routing, gavoille01routing} 
list several open problems
@@ -1045,8 +1045,8 @@
 
 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 Peer-to-Peer 
system is able to 
-deal with software failures and hostile attack, but fault tolerance against 
external threats is unknown. 
+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
 this kind of solution would be applicable. 
@@ -1059,56 +1059,54 @@
 \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 ''super-peer'' 
method presented in chapter
-2, there has been other improvements also. 
-In iterative deepening 
+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 
 \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
-originator starts a data lookup with small TTL value. If the search is not 
successful,
+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 maximum depth $D$ 
+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.
 
 Directed BFS \cite{yang02improvingsearch} optimizes the original 
-BFS in a way that peer selects neighbors with many quality results are reached 
in the past, 
+BFS in a way that a peer selects neighbors with many quality results are 
reached 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.
 
-Local indices \cite{yang02improvingsearch} is one variation of active caching. 
+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
 over its local content.}. Mutual index caching architecture, as proposed in 
 \cite{osokine02distnetworks}, is one variation of local indices technique. 
 
-In random walk approach \cite{lv02searchreplication}, peer forwards query to 
-randomly selected neighbor. The basic random walk approach decreases the
-overhead generated by messages. On the other hand, basic random walk approach
-has poor response time. As suggested in \cite{lv02searchreplication},
+In 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
 Depth-First-Search (DFS) and peers' routing tables are dynamically built
-using caching. This is an outcome of Freenet's main design principles, 
-i.e., anonymity. Another property of Freenet's data lookup model is that
+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
-''small-world phenomenon'' has been proposed by Zhang et al. 
\cite{zhang02using}.
+the ''small-world phenomenon'' has been proposed by Zhang et al. 
\cite{zhang02using}.
 
-
-Since tightly structured systems have efficient data lookup at the application 
level overlay,
-current research efforts are focused on proximity based data lookup. In 
proximity based data lookup, 
+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, 
 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
-proximity based routing. Additionally, most recent version of Chord uses 
proximity based 
+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 \emph{constrained load balancing}.
+lookups. Authors call this feature as a \emph{constrained load balancing}.
 
 Additional research related to proximity based routing include 
\cite{karger02findingnearest, hildrum02distributedobject, 
 brinkmann02compactplacement, rhea02probabilistic, castro02networkproximity, 
ng02predicting, pias03lighthouse}.
@@ -1124,20 +1122,20 @@
 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 
-\cite{li03feasibility} on top of tightly structured overlays. Authors argue, 
that it is possible to implement 
+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 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 
 observe 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 data 
lookup model of the loosely 
+in tightly structured overlays. Other approaches include adaption of the data 
lookup model of the loosely 
 structured approach into tightly structured systems 
\cite{ansaryefficientbroadcast03, chord:om_p-meng}.
-Some studies include additional layer upon overlay network 
\cite{kronfol02fasdsearch, joseph02p2players} 
+Some studies suggest additional layer upon overlay network 
\cite{kronfol02fasdsearch, joseph02p2players} 
 and range queries \cite{andrzejak02rangequeries}.
 
 Many techniques have been developed in order to provide more efficient search 
indexing. As 
 several studies show, the popularity of queries in the Internet follow 
Zipf-like 
-distributions\footnote{Zipf distribution is a variant of power-law function. 
+distributions\footnote{Zipf-distribution is a variant of power-law function. 
 Zipf-distribution can be used in observation of frequency of occurrence event 
$E$, as a function of the rank 
 $i$ when the rank is determined by the frequency of occurrence, $E_i \sim 
\frac{1}{i^{a}}$, where the exponent 
 $a$ is close to unity.} (e.g., \cite{breslau98implications}). Therefore, 
caching and pre-computation
@@ -1148,7 +1146,7 @@
 and clustering with their search optimizations.
 
 
-While it is expected that web-like searches can be layered on top of tightly 
structured overlay, much
+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.
 
 
@@ -1159,60 +1157,59 @@
 systems require less system management properties than tightly structured 
systems; in a loosely
 structured system, peers join and leave the system constantly without any 
restrictions. On the
 other hand, however, peers in tightly structured system join and leave the 
system but have less freedom, 
-i.e. overlay chooses peer's neighbors on behalf of peer itself and maps data 
items randomly 
+i.e., overlay chooses peer's neighbors on behalf of the peer itself and maps 
data items randomly 
 throughout the overlay network. 
 
-Current research has been focused on system management of tightly structured 
systems, and all presented
-algorithms of the tightly structured approach have been analyzed under static 
simulation environments. Furthermore, proposed 
-tightly structured overlays are configured statically to achieve the desired 
reliability even in 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. 
+All presented algorithms of the tightly structured approach have been analyzed 
under static simulation 
+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. 
 
-A concept of ''half-life'' was introduced by Liben-Nowell 
\cite{libennowell01observations} as Peer-to-Peer 
-system is \emph{never} in ''ideal'' state as it is continiously evolving 
system. Half-life is defined
+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
 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 
 time $t$ is smaller of the properties stated above. The half-life of the 
entire system is the 
 minimum half-life over all times $t$. Concept of half-time can be used as a 
basis for developing
-more efficient analytical tools for modeling complex Peer-to-Peer systems. 
+more powerful analytical tools for modelling complex Peer-to-Peer systems. 
 
 Some research has been done with regard to load balancing properties of 
tightly structured
-overlays. Byers et al. suggest "power of two choices" whereby data item is 
stored at the less loaded 
+overlays. Byers et al. suggest an idea of ''power of two choices'' whereby 
data item is stored at the less loaded 
 of two (or more) random peer alternatives \cite{byers03dhtbalancing}. Rao et 
al. use virtual servers
-to control load balance in Peer-to-Peer systems \cite{rao03loadbalancing}. 
Their work rests on the
+to control the load balance in a Peer-to-Peer system 
\cite{rao03loadbalancing}. Their work rests on the
 idea which was originally introduced by Chord \cite{stoica01chord} system.
 
 Also, query and routing hot spots may be an issue in tightly structured 
overlays \cite{ratnasamy02routing}. 
-Hot spots happen, when 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 
 by Freedman et al. tries to reduce hot spots in the system by performing 
\emph{sloppy} hashing 
 \cite{sloppy:iptps03}. Another key feature of their work is that peers 
self-organize into clusters, 
 therefore enabling peers to find nearby data without looking up data from 
distant peers.
 
 As mentioned before, an implicit assumption of almost every tightly structured 
system is that there is a random, uniform 
 distribution of peer and key identifiers. Even if participating peers are 
extremely heterogeneous, e.g., in
-face of 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
 a serious problem of tightly structured overlays in face of performance and 
load balancing. Measurement study 
-by Saroiu et al. shows that there is extreme heterogeneity among participating 
peers in already deployed Peer-to-Peer 
+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
 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 idea that
+groups in 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 to Peer-to-Peer environment. More promising 
work has been done by Rowston et al.
+is fault tolerant and suitable for a 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 tightly structured overlay 
\cite{zhang03somo}. They
-call their proposal as \emph{data overlay}, since it supports several 
fundamental data structures.
+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
-for monitoring health of tightly structured overlay. Fault tolerance of SOMO 
itself is currently
+for monitoring the health of a tightly structured overlay. The fault tolerance 
of SOMO itself is currently
 unknown. 
 
 
@@ -1234,11 +1231,12 @@
 
 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.
-However, these assumptions are not true as several studies show. Peers rather 
consume than contribute and
-peers are unwilling to cooperate \cite{saroiu02measurementstudyp2p, 
oram01harnessingpower, hearn02mojonation}. 
+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. 
 
 Somewhat surprisingly little research has been done in this area, especially 
when considering 
-the possible impact of \emph{unwanted social behavior} to performance of 
Peer-to-Peer 
+the possible impact of \emph{unwanted social behavior} to performance of a 
Peer-to-Peer 
 system. The problem is addressed by Golle et al. \cite{golle01incentivesp2p}, 
Ngan et al. 
 \cite{ngan03enforcefile} and Shneidman et al. \cite{shneidman03rationality}. 
Some 
 research has been focused on semantic properties of the overlay in order to 
increase 
@@ -1258,22 +1256,20 @@
 and rapid change. Obviously, these factors exist also in Peer-to-Peer systems 
even with higher
 rates.
 
-As long as comprehensive simulations of Peer-to-Peer systems are lacking, we 
cannot make any detailed
+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 
-that, e.g., query keywords follow the Zipf-like distributions 
\cite{breslau98implications} both in the 
+that, e.g., query keywords follow the Zipf-like distribution 
\cite{breslau98implications} both in the 
 Internet and in Peer-to-Peer systems.
 
 \section{Summary}
 
-In this section we summarize open problems in Peer-to-Peer systems. All open 
problem entries 
+In this section we summarize open problems in Peer-to-Peer systems. All the 
open problem entries 
 listed in this section are not necessarily mentioned in the previous sections. 
Problems listed 
-here are variations of previously mentioned problems, or otherwise related to 
them. For each entry, 
-there is a brief description of the problem, possible solutions and comments 
respectively.
+here are variations of previously mentioned problems, or otherwise related to 
them. 
 
-Next, we list open problems in Peer-to-Peer domain. In table 
\ref{table_security_problems_Peer-to-Peer} 
-open problems related to security are listed; in table 
\ref{table_performanceusability_problems_Peer-to-Peer} 
-problems related to performance are listed; in table 
\ref{table_Miscellaneous_problems_Peer-to-Peer} 
-miscellaneous open problems are listed.
+In table \ref{table_security_problems_Peer-to-Peer} open problems related to 
security are listed; in 
+table \ref{table_performanceusability_problems_Peer-to-Peer} problems related 
to performance are 
+listed; in table \ref{table_Miscellaneous_problems_Peer-to-Peer} miscellaneous 
open problems are listed.
 
 
 \scriptsize
@@ -1612,11 +1608,11 @@
 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, i.e., blocks. This should allow making 
references between data easier and more 
+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 
 uses Peer-to-Peer network for locating and fetching blocks.
 
-Fenfire is free software and it is licensed under GNU LGPL.  Fenfire was 
formerly also a partial implementation 
+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 
 by Ted Nelson. Now, however, Fenfire uses Resource Description Framework (RDF) 
\cite{w3rdfurl}
 for representing internal data structures and their relationships. 
@@ -1624,49 +1620,49 @@
 Fenfire is a high modular software system. It consists of several independent 
software modules:
 
 \begin{itemize}
-\item \textbf{Storm}: distributed storage module for storing arbitrary data 
items
-\item \textbf{Navidoc}: UML based tool for generating software documentation  
-\item \textbf{Alph}: xanalogical hypertext built upon Storm storage model
-\item \textbf{GLMosaicText}: flexible OpenGL interface for font manipulation
-\item \textbf{CallGL}: wrapping library used for OpenGL calls
-\item \textbf{LibVob}: graphic library used for creating navigation interfaces 
in complex data views
+\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{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 
-must have support for Peer-to-Peer functionality as it provides low-level data 
storage operations
+must have a support for Peer-to-Peer functionality as it provides low-level 
data storage operations
 in the Fenfire system.
 
 
 \section{Xanalogical storage model}
 
-Xanalogical storage \cite{nelson99xanalogicalneeded} is a different kind of 
model for 
-presenting data and relationships between data. While in World Wide Web links 
are
-between \emph{documents}, in xanalogical model links are between individual 
+Xanalogical storage model \cite{nelson99xanalogicalneeded} is a different kind 
of model for 
+presenting data and relationships between data. While in the World Wide Web 
links are
+between \emph{documents}, in xanalogical storage model links are between 
individual 
 \emph{characters}. Each character in xanalogical storage model has a
 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
-is copied to different document. Thus, the identifier distinguishes character 
from 
+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 xanalogical storage model between data 
content 
+frames of video.}. The connectivity in the 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,
-xanalogical storage model stores fluid media units to append-only 
\emph{scrolls}.
+the 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 contents. In xanalogical storage model, links between content 
are external 
-and bidirectional. Xanadu link is an \emph{association} of two enfilades, such 
as an 
+of fluid media content. In the 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 
xanalogical storage model
-is able to show all data content that share same fluid media with current data 
content
+different data contents. By using this mechanism, a system implementing the 
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.
 
@@ -1693,8 +1689,8 @@
 for creating location-independent, globally unique identifiers for blocks. 
Additionally,
 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, i.e., 
globally unique 
-identifier. This mechanism creates a basis for implementing xanalogical 
storage model in 
+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.
 
 \begin{figure}
@@ -1710,13 +1706,13 @@
 we discuss only pointers as they are part of the thesis' research problems. 
 More information about diffs can be found from \cite{fallenstein03storm}.
  
-Pointer \cite{benja02urn5} is a semantic-free, updatable reference to 
-Storm data block, i.e., Storm scroll block. 
+Pointer \cite{benja02urn5} is a semantic-free updatable reference to 
+Storm data block, named as Storm scroll block. 
 In practice, pointer is a random string, which resembles Universal Resource 
Names 
 (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 overall 
+target for the pointer. In figure \ref{fig:storm_model}, we present 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 
@@ -1734,47 +1730,47 @@
 
 \chapter{Evaluation of Peer-to-Peer for Fenfire}
 
-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
+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
 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 in Peer-to-Peer environment and present simple methods to 
perform data 
-lookups in Peer-to-Peer environment. In the end of this chapter, we discuss 
possible problems of using Fenfire
-in Peer-to-Peer environment.
+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.
 
 
 \section{Problem overview}
 
-As already mentioned in chapter 4, xanalogical document is a ''virtual
+As already mentioned in chapter 4, a xanalogical document is a ''virtual
 file'', in which parts of the document are fetched from a 
-\emph{global} data repository. Thus, system implementing xanalogical model 
\emph{must}
-support global data lookups efficiently in order to assemble a ''virtual file''
+\emph{global} data repository. Thus, system implementing the 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 
-unique identifier. In the Fenfire system, data fragments are scroll blocks, 
generated by Storm storage module.
+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.
 Therefore, our task is to locate and fetch (i.e. obtain) \emph{all} Storm 
scroll blocks, associated to a specific ''virtual 
-file'', from Peer-to-Peer overlay as efficiently as possible. In addition to 
+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 \emph{indirect} obtaining of Storm scroll block using 
pointer blocks.
+we also must support the \emph{indirect} obtaining of Storm scroll block using 
pointer blocks.
 
-Obviously, our objectives are yet simple but hard to fulfill. First, as a 
prerequisite
-to implementing xanalogical storage model in Peer-to-Peer environment, system
+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
 supporting data lookups must be able to perform \emph{global} scale lookups. 
Thus, 
-we must be able to locate and fetch Storm scroll/pointer block, if it exists 
in the 
+we must be able to locate and fetch 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 ''virtual 
file''
+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.
 
 Some research regarding to these problem has been made by Lukka et al. 
-\cite{lukka02freenetguids}. Authors' work is mainly based on insight of 
implementing
-xanalogical model in Peer-to-Peer environment with globally unique 
identifiers. 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.
 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.
@@ -1796,7 +1792,7 @@
 data lookup model of tightly structured overlay scales much better than 
loosely 
 structured overlays; 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 overlay\footnote{The area depends on where the 
query
+is limited to 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 
@@ -1806,38 +1802,38 @@
 feature is almost analogical 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 widely used RRS system in the 
Internet.}
+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 
 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 Peer-to-Peer
+Thus, we see the tightly structured approach as the best alternative to locate 
data in a Peer-to-Peer
 environment.
 
-Once located, for \emph{fetching} Storm blocks from the overlay, we can use 
regular 
-TCP/IP-protocols, such as Hypertext Transfer protocol (HTTP) \cite{rfc2068}. 
However, HTTP-protocol may 
-not be optimal when obtaining large amounts of data from the Peer-to-Peer 
network (e.g., 
+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., 
 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 certain peer, thus 
avoiding query 
+multisource downloads can be used for decreasing load of a certain peer, thus 
avoiding query 
 hot spots in the system \cite{ratnasamy02routing}. Current implementation of 
Fenfire uses 
 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 hash\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, e.g., a 
file) from 
-other source.}, such as \cite{merkle87hashtree, mohr02thex} for reliable and 
efficient 
+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 
 data validation.
 
 Again, there are research challenges with tightly structured systems which 
have to be
 addressed, as described in chapter 3. The main concerns include decreased 
performance and fault 
-tolerance when system in presence of system flux, non-optimal distance 
functions in identifier space, 
+tolerance in presence of system flux, non-optimal distance functions in 
identifier space, 
 proximity routing, hostile entities and flexible search 
\cite{balakrishanarticle03lookupp2p}.
 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 issues are 
+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 
 overlays \cite{projectirisurl}.
 
@@ -1845,15 +1841,15 @@
 \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 yet 
simple but 
-effective methods for obtaining Fenfire data from Peer-to-Peer environment. 
+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. 
  
 \subsection{System proposal}
 
 Currently, we see Kademlia \cite{maymounkov02kademlia} as the best algorithm 
for
-locating data efficiently in the Peer-to-Peer overlay. There are two main
+locating data efficiently in the Peer-to-Peer overlay. There are two
 reasons for this. First, Kademlia's XOR-based distance function is superior
-over the distance functions of other systems (see section 2.4). Second, there 
exist already  
+over distance functions of other systems (see section 2.4). Second, there 
exist already  
 deployed real-life systems using Kademlia (e.g., \cite{overneturl, 
edonkey2kurl, kashmirurl,
 kato02gisp}), which means that Kademlia's algorithm is simple and easy to 
implement.
 
@@ -1871,35 +1867,35 @@
 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 downloads, 
we can use
+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
 on rateless erasure codes \cite{maymounkov03ratelesscodes} seems very 
promising.
 
 \subsection{Methods}
 
 We use the DOLR abstraction of the tightly structured approach, i.e., each 
participating peer hosts 
-the data and overlay maintains only the \emph{pointers} to the data. We 
decided to use the DOLR 
+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 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 
-mapping function of the overlay. These systems waste both storage and 
bandwidth, and
+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 
+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}
 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.
 
 In the following subsections we assume that we know the structure of 
-''virtual file'' before hand, i.e., when assembling a ''virtual file'', we 
know all Storm 
-scroll/pointer blocks, which are required when building the ''virtual file''. 
Also, we don't 
+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
 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: data structure for listing all 
-key/value-pairs which peer maintains; data structure for listing all 
key/value-pair in 
+In our model, each peer maintains 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-pairs consists of either a hash 
of pointer random string 
+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.
@@ -1909,39 +1905,39 @@
 \item Data lookup with a given identifier of Storm scroll block.
 \begin{enumerate}
 \item Submit data lookup using scroll block's identifier.
-\item Repeat until hosting peer is found: each peer forwards the data lookup 
to a closer peer which hosts the given scroll block identifier.
-\item Pointer peer returns value (e.g., the IP address of provider peer) to 
query originator.
-\item Query originator requests provider peer to return the scroll block.
+\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 Storm scroll block is 
located 
-in tightly structured overlay using the DOLR abstraction, where identifier of 
Storm scroll 
+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.
 
 
 \begin{itemize}
 \item Data lookup with a given pointer random string returning most recent 
scroll block.
 \begin{enumerate}
-\item Query originator locally computes a hash for given pointer random string.
-\item Repeat until hosting peer is found: each peer forwards the data lookup 
to a closer peer which hosts the given hash of pointer random string.
-\item Pointer peer returns most recent pointer block's key/value-pair (e.g., 
the IP address of provider peer) to query originator, using pointer block's own 
indexing schemes. 
-\item Query originator requests provider peer to return the scroll block.
+\item The query originator locally computes a hash for 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.
 \end{enumerate}
 \end{itemize}
 
 \begin{itemize}
-\item Data lookup with a given pointer random string returning scroll block(s) 
for a given date and/or time range.
+\item Data lookup with a given pointer random string returning scroll block(s) 
for a given date or time range.
 \begin{enumerate}
-\item Query originator locally computes a hash for given pointer random string.
-\item Repeat until hosting peer is found: each peer forwards the data lookup 
to a closer peer which hosts the given hash of pointer random string.
-\item Pointer peer returns pointer block's key/value-pair(s) (e.g., the IP 
address of provider peer) to query originator, using pointer block's own 
indexing schemes. 
-\item Query originator requests provider peer to return the scroll block.
+\item The query originator locally computes a hash for 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.
 \end{enumerate}
 \end{itemize}
 
 Figure \ref{fig:storm_query_urn5} illustrates how Storm scroll block is 
located 
-in tightly structured overlay using the DOLR abstraction, where pointer random 
string is known.
+in tightly structured overlay using the DOLR abstraction, where the pointer 
random string is known.
 
 Each of these algorithms can locate Fenfire data in $O(\log{n})$ time at 
application level overlay:
 $O(\log{n})$ time for query routing to pointer peer and constant time for 
@@ -1968,15 +1964,15 @@
 Perhaps the most biggest issue in Peer-to-Peer systems is 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 global data lookup 
with a given
-pointer random string; how can the user verify the correctness
+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 
-correct Storm scroll block ? Spam attack \cite{naor03simpledht} is a variation 
of previously
+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
 data really doesn't exist in the system ? Another problem related to the 
Fenfire's 
 security is that if a user downloads data from the network to local computer 
-and after network disconnection, user wants to verify \emph{off line} the 
+and after a network disconnection, user wants to verify \emph{off line} the 
 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 
@@ -1989,40 +1985,39 @@
 
 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 three sub-categories: security 
related problems,
+Specifically, we divided open problems into the three sub-categories: security 
related problems,
 performance related problems and miscellaneous problems. 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.
 
 Then, we focused our attention to the Fenfire system. First, we gave a brief
-overview of Fenfire and xanalogical model. We also described Storm software 
module.
+overview of Fenfire 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
 best alternative to Fenfire's needs for the following reasons. First, Storm, 
xanalogical
-model and tightly structured systems use global unique identifiers
+storage model and tightly structured systems use global unique identifiers
 for identifying data. Second, our Storm design uses \emph{semantic-free 
references} 
-(block identifiers, pointer random strings) for locating data in distributed 
-networks generated by SHA-1 cryptographic content
-hash \cite{fips-sha-1}. As the authors of \cite{balakrishnan03semanticfree},
-we also agree that tightly structured overlays provide general purpose
-interface to next-generation reference resolution services. Third, by using 
+(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 
+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 near future, because of
+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 in Peer-to-Peer environment and 
-presented simple methods to perform data lookups in Peer-to-Peer environment.
+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 showed
+and xanalogical links in a global scale. 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 
 database systems may prove to be useful. Some fundamental results
-regarding Peer-to-Peer and database systems has already been
+regarding Peer-to-Peer and database systems have already been
 presented in \cite{gribble01p2pdatabase}.  
 
 In the following months, we will implement a Fenfire Peer-to-Peer prototype.