[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/14 07:12:26

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

Log message:
        Updates and corrections

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

Patches:
Index: gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
diff -u gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.145 
gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.146
--- gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.145      Fri Mar 
14 04:08:50 2003
+++ gzz/Documentation/misc/hemppah-progradu/masterthesis.tex    Fri Mar 14 
07:12:12 2003
@@ -869,8 +869,8 @@
 
 \subsection{Attacks}
 
-There are five well known attack models against Peer-to-Peer systems: Sybil 
attack \cite{douceur02sybil},
-Fail-stop attack, Spam attack \cite{naor03simpledht}, Byzantine problem 
\cite{357176} and \cite{296824}, and
+There are five known attack models against Peer-to-Peer systems: Sybil attack 
\cite{douceur02sybil},
+Fail-stop attack, Spam attack \cite{naor03simpledht}, Byzantine attack 
\cite{357176} and \cite{296824}, and
 general Distributed Denial of Service attack. 
 
 In Sybil attack model, hostile entity presents multiple 
@@ -895,17 +895,16 @@
 Possible solution against this attack is that peer should not trust to single 
entity. Instead, peer should get 
 information from multiple entities and trust on majority's opinion. This 
method requires more messages to be 
 sent to network while increasing system load. However, if Spam attack is 
combined with Sybil attack, obviously 
-previously mentioned solution doesn't work. Again, more research is required 
to solve this attack model 
-safely. Naor et al. \cite{naor03simpledht} has proposed a partial solution 
against Spam attack with 
-\emph{faulty} peers (not hostile).
+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).
 
 Traditional overloading of targeted peers is best known form of distributed 
Denial of Service attack (DDoS). For example, 
 hostile entity can attempt to burden targeted peers with garbage network 
packets. As an implication, peers may act
 incorrectly or stop working. DDoS attack may be very severe, especially if 
rate of replication and caching 
 in Peer-to-Peer system is low. This may lead to data loss in the Peer-to-Peer 
system. Daswani et al. 
-\cite{daswani02queryflooddos} has done research regarding to this subject. 
Authors suggest efficient load balancing 
+\cite{daswani02queryflooddos} have done research regarding to this subject. 
Authors suggest efficient load balancing 
 policies for Peer-to-Peer system in order to prevent massive system failures. 
Sit et al. \cite{sit02securitycons} 
-suggests that identifier assignment algorithm for peers would assign 
identifier with respect to network topology 
+suggest that identifier assignment algorithm for peers would assign identifier 
with respect to network topology 
 and replicas should be located physically to different locations.
 
 As stated in \cite{naor03simpledht}, an important aspect is that when it comes 
to general security aspects and 
@@ -916,10 +915,10 @@
 \subsection{Trust, data authenticity and integrity}
 
 Trust in Peer-to-Peer systems is based on \emph{reputation}. Proposed 
reputation methods focus either
-on the semantic properties, or data management properties of the trust model. 
Some research has been 
+on the semantic properties, or the data management properties of the trust 
model. Some research has been 
 done on reputation models in Peer-to-Peer systems, such as 
\cite{aberer01trust}, \cite{cornelli02reputableservents}. 
 One implementation include Advogato \cite{advogatourl}. None of the current 
proposals or implementations 
-based on reputation address trust in a reliable way.
+based on reputation address trust in a reliable, practical way.
 
 Optimal solution for trust in Peer-to-Peer systems would be certificate based 
security models.
 Quite recently, widely used Public Key Infrastructure (PKI) has been deployed 
in distributed
@@ -964,7 +963,7 @@
 Peer-to-Peer system. Let's consider anonymity and efficient data lookup. In 
efficient data lookup, we must know
 the peers responsible for given data in Peer-to-Peer system. 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 \emph{pseudonym} which is a partial form of 
anonymity. For instance, pseudonym can be used for 
+mentioned situations, such as pseudonym which is a partial form of anonymity. 
For instance, pseudonym can be used for 
 addressing peer-anonymity by providing anonymous-like identifiers to peers 
(e.g., peer identifiers of tightly 
 structured system).
 
@@ -992,7 +991,7 @@
 
 To our knowledge, Nejdl et al. \cite{nejdl03accesscontrol} have proposed very 
recently first practical solution to access 
 control problem in Peer-to-Peer systems. They use Resource Description 
Framework (RDF) \cite{w3rdfurl} based 
-schema policies to restrict access to certain data. Unfortunately, their 
current prototype works only in 
+schema policies to restrict access to certain data. Unfortunately, their 
current early prototype version works only in 
 loosely structured systems.
 
 
@@ -1006,14 +1005,13 @@
 approach, in which fundamental (and implicit) assumption is that there is a 
random, uniform distribution 
 of peer identifiers that cannot be controlled by hostile entity.
 
-Of course centralized authorities could be used for assignment of peer 
identifiers, but they have 
-property of single point of failure. Furthermore, 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 
identifier, such as crypto-based
-puzzles \cite{juels99clientpuzzles}.
+Of course centralized authorities could be used for 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 
+identifier, such as crypto-based puzzles \cite{juels99clientpuzzles}.
 
-In the end, none of the previously mentioned solutions are able to identify 
hostile entities in practical,
-efficient way. More research is required to solve these problems.
+In the end, none of the previously mentioned solutions are able to identify 
hostile entities safely. 
 
 
 \subsection{Secure query routing}
@@ -1021,8 +1019,8 @@
 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.
-Additionally, authors present an important aspect of tightly structured 
approach with regard
-to fault-tolerant query routing: the probability of routing successfully 
between to arbitrary, 
+Additionally, authors present in \cite{castro02securerouting} an important 
aspect of 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
 $h$ is the number of hops in the overlay.
 
@@ -1056,7 +1054,7 @@
 \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 Trojan. Currently, there are not even partial 
solutions
+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. 
 The reason for this is that there are no experiences on these kinds of 
attacks. Possible solution 
@@ -1064,11 +1062,9 @@
 this kind of solution would be applicable. 
 
 
-
-
 \section{Performance and usability problems in Peer-to-Peer}
 
-In this section, we discuss performance related issues regarding Peer-to-Peer 
systems.
+In this section, we discuss performance issues regarding Peer-to-Peer systems.
 
 \subsection{Efficient data lookup}
 
@@ -1082,12 +1078,12 @@
 originator starts a data lookup with 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$ 
-has been reached. Expanding ring, proposed by Shenker et al., 
\cite{lv02searchreplication}, 
+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 
earlier, 
+BFS in a way that 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.
@@ -1124,27 +1120,25 @@
 uses combination of proximity and application level overlay routing when 
performing data 
 lookups. Authors call this feature \emph{constrained load balancing}.
 
-Research related to proximity based routing include 
\cite{karger02findingnearest}, 
+Additional research related to proximity based routing include 
\cite{karger02findingnearest}, 
 \cite{hildrum02distributedobject}, \cite{brinkmann02compactplacement}, 
\cite{rhea02probabilistic},
-\cite{castro02networkproximity}, \cite{ng02predicting} and 
\cite{pias03lighthouse}. However,
-more research is required to make latency heuristic more effective and 
practical.
-
+\cite{castro02networkproximity}, \cite{ng02predicting} and 
\cite{pias03lighthouse}.
 
 \subsection{Fast and usable search}
 
 To make Peer-to-Peer systems even more popular (and usable), these systems 
have to support flexible, efficient
 and easy to use search methods. For instance, Internet's perhaps the most 
important feature
-is the ability to perform keyword or fuzzy searches (e.g., Google). Currently, 
only loosely
+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 loosely structured approach is not scalable. Thus, 
research efforts have
-been focused on tightly structured approach. 
-The main problem with tightly structured approach is the fact that tightly 
structured algorithms
-perform data lookups based on a globally unique identifier (key). Quite 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 
Peer-to-Peer Web-like search with certain radical 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 observe better the properties of 
underlying network for
-better performance. 
+the data lookup model of 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 
+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 
+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 
+observe better 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 loosely 
@@ -1175,9 +1169,9 @@
 of any Peer-to-Peer system, since centralized control over the system is 
missing. Loosely structured
 systems require less system management properties than tightly structured 
systems; in loosely
 structured system, peers join and leave the system constantly without any 
restrictions. On the
-other hand, however, peers in tightly structured system have less freedom, 
i.e. overlay chooses peer's
-neighbors on behalf of peer itself and maps data items randomly throughout the 
overlay network. However,
-Peer-to-Peer system is \emph{never} in ''ideal'' state as it is continiously 
evolving system.
+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 
+throughout the overlay network. 
 
 Current research has been focused on system management of tightly structured 
systems, and all presented
 algorithms of tightly structured approach have been analyzed under static 
simulation environments. Furthermore, proposed 
@@ -1186,7 +1180,8 @@
 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}. Half-life is defined
+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
 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 
@@ -1196,7 +1191,7 @@
 
 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 
-of two (or more) random peer alternatives \cite{byers03dhtbalancing}. Rao et 
al. uses virtual servers
+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
 idea which was originally introduced by Chord \cite{stoica01chord} system.
 
@@ -1234,7 +1229,7 @@
 
 \section{Miscellaneous problems in Peer-to-Peer}
 
-In this section we discuss miscellaneous problems related to Peer-to-Peer 
systems.
+In this section we discuss miscellaneous problems in Peer-to-Peer systems.
 
 \subsection{Programming guidelines and benchmarks}
 
@@ -1288,8 +1283,8 @@
 there is a brief description of the problem, possible solutions and comments 
respectively.
 
 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}, 
+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.
 
 
@@ -1496,8 +1491,8 @@
 
 \parbox{90pt}{Hot spots \cite{258660}, \cite{sloppy:iptps03}, 
\cite{maymounkov03ratelesscodes}} &
 \parbox{110pt}{What will happen if some resource is extremely popular and only 
one peer is hosting it ?} &
-\parbox{110pt}{Caching, multi source downloads, replication, load balancing, 
sloppy hashing} &
-\parbox{110pt}{For query hot spots, caching and multi source downloads 
efficiently reduce hot spots, for routing hot spots, benefits are smaller}
+\parbox{110pt}{Caching, multisource downloads, replication, load balancing, 
sloppy hashing} &
+\parbox{110pt}{For query hot spots, caching and multisource downloads 
efficiently reduce hot spots, for routing hot spots, benefits are smaller}
 \\ \hline
 
 
@@ -1622,7 +1617,7 @@
 \chapter{Fenfire hypermedia system}
 
 In this chapter we give an overview of Fenfire system. We also 
-describe briefly xanalogical model. At the end of this chapter we study Storm, 
+describe briefly xanalogical storage model. At the end of this chapter we 
study Storm, 
 Fenfire's software module, which is an essential part of Fenfire's 
Peer-to-Peer 
 functionality. 
 
@@ -1635,7 +1630,7 @@
 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 L-GPL.  Fenfire was 
formerly also a implementation 
+Fenfire is free software and it is licensed under GNU L-GPL.  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. 
@@ -1652,10 +1647,13 @@
 \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' 
referring to both
-Storm and Alph software modules.
+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 Fenfire system, 
Storm software module 
+must have support for Peer-to-Peer functionality as it provides low-level data 
storage operations
+in Fenfire system.
 
-\section{Xanalogical model}
+
+\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
@@ -1672,8 +1670,8 @@
 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 handle storage operations. This is done for better 
performance as
-doing expensive operations for every fluid media unit is not efficient. 
Moreover,
+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}.
 
 \emph{Enfilade} can be considered as a ''virtual file'' (or part of one), 
which is a list
@@ -1709,8 +1707,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., unique 
-identifier. This mechanism creates a basis for implementing xanalogical model 
in 
+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 
 Fenfire system. Figure \ref{fig:storm_model} illustrates simplified Storm 
storage model.
 
 \begin{figure}
@@ -1735,7 +1733,7 @@
 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 
-block will 'obsolete' the pointer block targeting the superseded version. Next 
+block will ''obsolete'' the pointer block targeting the superseded version. 
Next 
 time, when the pointer is used for referring to a specific scroll block, only 
 the most recent pointer's block target is loaded.
 
@@ -1754,7 +1752,7 @@
 environment. We define Fenfire's special needs and evaluate existing 
 Peer-to-Peer approaches in light of these requirements. After that, we propose 
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, we discuss possible problems 
of using Fenfire
+lookups in Peer-to-Peer environment. In the end of this chapter, we discuss 
possible problems of using Fenfire
 in Peer-to-Peer environment
 
 
@@ -1782,7 +1780,7 @@
 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 
 Peer-to-Peer overlay. Second, data lookups have to be efficient, since 
constructing 
-one ''virtual file'' may need obtaining several data items, which are 
distributed 
+one ''virtual file'' may need obtaining several Storm blocks, which are 
distributed 
 randomly throughout the overlay; if not efficient, construction of ''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.
@@ -1826,27 +1824,27 @@
 application-independent and references itself should be \emph{unstructured} 
and 
 \emph{semantic 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 \emph{distributed} 
hypermedia system.
+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
 environment.
 
 Once located, for \emph{fetching} Fenfire related data 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 
overlay, for 
-instance videos, images or music. In this case, multi source downloads can be 
very useful 
+not be optimal when obtaining large amounts of data from the Peer-to-Peer 
network (e.g., 
+videos, images or music). In this case, multisource downloads can be very 
useful 
 for better efficiency \cite{maymounkov03ratelesscodes}, \cite{bittorrenturl}. 
Furthermore, 
-multi source downloads can be used for decreasing load of certain peer, thus 
avoiding query 
+multisource downloads can be used for decreasing load of 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 multi source downloads, Fenfire must support
-tree-based hash\footnote{With multi source downloads, tree based hash 
functions can be used 
+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 
 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} and \cite{mohr02thex} for 
reliable and efficient 
 data validation.
 
-Again, there are open issues with tightly structured systems which have to be
+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, 
 proximity routing, hostile entities and flexible search 
\cite{balakrishanarticle03lookupp2p}.
@@ -1868,12 +1866,12 @@
 Currently, we see Kademlia \cite{maymounkov02kademlia} as the best algorithm 
for
 locating data efficiently in the Peer-to-Peer overlay. There are two main
 reasons for this. First, Kademlia's XOR-based distance function is superior
-over the distance functions of other systems. Second, there are already some 
-real-life systems (e.g., \cite{overneturl}, \cite{edonkey2kurl}, 
\cite{kashmirurl},
+over the distance functions of other systems (see section 2.4). Second, there 
exist already  
+deployed real-life systems using Kademlia (e.g., \cite{overneturl}, 
\cite{edonkey2kurl}, \cite{kashmirurl},
 \cite{kato02gisp}), which means that Kademlia's algorithm is simple and easy 
to implement.
 
 On top of Kademlia, we propose the usage of Sloppy hashing 
\cite{sloppy:iptps03} which
-is optimized for DOLR abstraction of tightly structured overlays. With Sloppy 
hashing, 
+is optimized for the DOLR abstraction of tightly structured overlays. With the 
Sloppy hashing, 
 we are able to reduce the generation of query hot spots. Sloppy hashing 
enables to 
 locate nearby data without looking up data from distant peers. Moreover, 
authors' 
 proposal for self-organizing clusters using network diameters may be useful, 
@@ -1887,7 +1885,7 @@
 
 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
-multi source downloads for better efficiency and reliability. Specifically, 
technology based
+multisource downloads for better efficiency and reliability. Specifically, 
technology based
 on rateless erasure codes \cite{maymounkov03ratelesscodes} seems very 
promising.
 
 \subsection{Methods}
@@ -1899,7 +1897,7 @@
 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 wastes both storage and 
bandwidth, and
-are sensitive to certain attacks (e.g., DDoS attack). Additionally, we prefer 
\emph{abstraction}
+are sensitive to certain attacks (e.g., DDoS attack). Additionally, we 
emphasize that we prefer \emph{abstraction}
 level analysis as very recently better and better tightly structured 
algorihtms 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.
@@ -1916,7 +1914,7 @@
 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 
 (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. 
+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.
 
 
@@ -1925,13 +1923,13 @@
 \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 most recent pointer block's value (e.g., hosting 
peer's IP address) to query originator.
-\item Query originator requests hosting peer to return the scroll block.
+\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.
 \end{enumerate}
 \end{itemize}
 
 Figure \ref{fig:storm_query_blockid} illustrates how Storm scroll block is 
located 
-in a tightly structured overlay using DOLR method, where identifier of Storm 
scroll 
+in a tightly structured overlay using the DOLR abstraction, where identifier 
of Storm scroll 
 block is known.
 
 
@@ -1940,29 +1938,27 @@
 \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., 
hosting peer's IP address) to query originator, using pointer block's own 
indexing schemes. 
-\item Query originator requests hosting peer to return the scroll block.
+\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.
 \end{enumerate}
 \end{itemize}
 
 \begin{itemize}
-\item Data lookup with a given pointer random string returning scroll block(s) 
for a given date and time range.
+\item Data lookup with a given pointer random string returning scroll block(s) 
for a given date and/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., hosting 
peer's IP addresses) to query originator, using pointer block's own indexing 
schemes. 
-\item Query originator requests hosting peer to return the scroll block.
+\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.
 \end{enumerate}
 \end{itemize}
 
 Figure \ref{fig:storm_query_urn5} illustrates how Storm scroll block is 
located 
-in a tightly structured overlay using DOLR method, where pointer random string 
is known.
+in a tightly structured overlay using the DOLR abstraction, where pointer 
random string is known.
 
-Each of these algorithms can locate Fenfire related data in $O(\log{n})$ time:
+Each of these algorithms can locate Fenfire related data 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. Time required for 
transferring
-the data is not included.
+locating hosting peer with a given reference link.
 
 
 \begin{figure}
@@ -1987,17 +1983,17 @@
 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 the user is able to verify the correctness
-of the search results, and how do we know which one is the 
+of the search results ? Specifically, how she/he knows which one is the 
 correct Storm scroll block ? Spam attack \cite{naor03simpledht} is a variation 
of previously
-mentioned problem; data lookup is performed by user, but there is no reply
+mentioned problem; data lookup is performed by a user, but there is no reply
 from the system. How we are able to know if this was a spam attack, or the
 data really doesn't exist in the system ? Another problem related to 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 
 authenticity of data. Obviously, optimal solution to all security issues would 
-be that digital signatures are included to every message sent to the system. 
-However, these problems are not only limited to Fenfire, it concerns all 
-Peer-to-Peer based computer systems.
+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 Fenfire as it concerns all Peer-to-Peer based computer systems.
 
 As security technologies come more mature, we wish to apply these 
 technologies with Fenfire, if applicable.
@@ -2005,16 +2001,15 @@
 \chapter{Conclusions and future work}
 
 In this thesis, we have reviewed existing Peer-to-Peer approaches, algorithms 
and
-their properties.  We summarized open problems in Peer-to-Peer networks. 
Specifically,
-we divided open problems into three sub-categories: security related problems,
+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,
 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 open problems.
+solve these problems.
 
 Then, we focused our attention to Fenfire system. First, we gave a brief
-overview of Fenfire and xanalogical model. We also described Storm, 
-which is an essential part of Fenfire's Peer-to-Peer functionality.
+overview of Fenfire and xanalogical 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 tightly structured approach is the
@@ -2031,14 +2026,17 @@
 related to tightly structured overlays are solved in 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.
+
 Our future work includes support for searching transclusions and xanalogical
 links in a Peer-to-Peer network. Specifically, we want to find transclusions
-or xanalogical links in a global scale. Preliminary analysis have showed
+and xanalogical links in a global scale. Preliminary analysis have showed
 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
-presented \cite{gribble01p2pdatabase}.  
+presented in \cite{gribble01p2pdatabase}.  
 
 In the following months, we will implement a Fenfire Peer-to-Peer prototype. 
 
Index: gzz/Documentation/misc/hemppah-progradu/progradu.bib
diff -u gzz/Documentation/misc/hemppah-progradu/progradu.bib:1.110 
gzz/Documentation/misc/hemppah-progradu/progradu.bib:1.111
--- gzz/Documentation/misc/hemppah-progradu/progradu.bib:1.110  Thu Mar 13 
08:47:15 2003
+++ gzz/Documentation/misc/hemppah-progradu/progradu.bib        Fri Mar 14 
07:12:15 2003
@@ -2154,3 +2154,8 @@
        url = {http://iptps03.cs.berkeley.edu/final-papers/rationality.ps}
 }  
 
address@hidden,
+       key = {Google},
+       title = {Google},
+       howpublished = {http://www.google.com}
+}