gzz-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Hermanni Hyytiälä
Subject: [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert...
Date: Thu, 06 Mar 2003 10:12:48 -0500

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Hermanni Hyytiälä <address@hidden>      03/03/06 10:12:35

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

Log message:
        updates

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

Patches:
Index: gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
diff -u gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.124 
gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.125
--- gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.124      Thu Mar 
 6 05:54:35 2003
+++ gzz/Documentation/misc/hemppah-progradu/masterthesis.tex    Thu Mar  6 
10:12:32 2003
@@ -27,7 +27,7 @@
 
 \tyyppi{Master's Thesis}
 
-\keywords{Peer-to-Peer, P2P, security, Distributed systems, Hypermedia systems}
+\keywords{Peer-to-Peer, P2P, security, distributed systems, hypermedia systems}
 
 \avainsanat{Vertaisverkot, P2P, tietoturva, hajautetut järjestelmät, 
hypermedia-järjestelmät}
 
@@ -92,12 +92,12 @@
 Dave Winer \cite{winer00whatisp2p} lists several
 properties of Peer-to-Peer network, while most notably the statement 
 ''The user's machine is a client and a server'' describes best Peer-to-Peer
-networks. To summarize, Peer-to-Peer systems can be characterized as 
distributed 
+systems. To summarize, Peer-to-Peer systems can be characterized as 
distributed 
 systems in which all communication is symmetric and all participants have 
identical 
 capabilities and responsabilities. Each \emph{peer} may contribute data or 
 computing resources (e.g., unused storage) to the overall system and the 
welfare 
-of the community can scale with ne number of participants. Thus, each 
participant 
-rely on one another services and resources, rather than solely relying on 
dedicated 
+of the community can scale with the number of participants. Thus, each 
participant 
+rely on one another's services and resources, rather than solely relying on 
dedicated 
 and centralized infracstructure. 
 
 One of the most important properties of any distributed computing system are 
efficient 
@@ -105,21 +105,22 @@
 focus on these aspects in Peer-to-Peer domain.
 Specifically, we review existing Peer-to-Peer approaches, algorithms and their 
key properties. We observe
 that despite of greate amount of proposed Peer-to-Peer systems, all systems 
fall either
-loosely structured approach or tightly structured approach. Then, we discuss 
open problems in 
+loosely structured approach or tightly structured approach. We also discuss 
open problems in 
 Peer-to-Peer networks and divide problems into three sub-categories: security 
related problems, 
 performance related problems and miscellaneous problems. In the end, we 
summarize all 
 problems in easy-to-understand tables. 
 
-Next, we give an overview of our Fenfire system, which implements xanalogical 
storage model. We
-also describe briefly Storm software module, which is an essential part of 
Fenfire's
+Next, we give an overview of our Fenfire hypermedia system, which implements 
xanalogical storage model. We
+also describe briefly Storm software module of Fenfire system, which is an 
essential part of Fenfire's
 Peer-to-Peer functionality. We evaluate existing Peer-to-Peer approaches and
-choose the best alternative to our needs. We discover that Storm, xanalogical 
model and
+choose the best alternative to our needs. We discover that Fenfire, 
xanalogical model and
 tightly structured Peer-to-Peer approach all have similar method to deal with 
data,
-i.e., globally unique identifiers. Finally, we propose yet simple but 
effective 
-algortihms to be used  with our Fenfire system in Peer-to-Peer environment. 
+i.e., globally unique identifiers. Finally, we propose system model for 
Fenfire in Peer-to-Peer
+environment and present yet simple but efficient algortihms to be used for 
data lookups in 
+Peer-to-Peer environment. 
 
 To our knowledge, this thesis is the most comprehensive work with regard to 
summarizing 
-existing Peer-to-Peer algorithms and open problems in Peer-to-Peer domain. 
However, this
+existing algorithms and open problems in Peer-to-Peer domain. However, this
 thesis is not meant to be detailed work. More detailed information can be 
found from genuine
 publications written by original authors.
 
@@ -127,25 +128,21 @@
 
 There are three research problems related to this thesis. First research 
problem
 is to find the most efficient way to locate and fetch Fenfire related data 
from the 
-Peer-to-Peer network, where Scroll block's identifier is given. Second, we want
+Peer-to-Peer network, where Storm scroll block's identifier is given. Second, 
we want
 to find the most efficient way to locate and fetch most recent Fenfire related 
data from the
-the Peer-to-Peer network, which is associated with a given urn-5 random 
string. Third problem
+the Peer-to-Peer network, which is associated with a given pointer random 
string. Third problem
 is otherwise same as the second problem, except we want to locate and fetch 
all Fenfire
 related data from the Peer-to-Peer network, where given date and/or time range 
is given.
 
-When comparing different Peer-to-Peer approaches and algorithms, we will 
examine their
-scalability, efficiency, space requirements for neighbor connections and 
overhead
-associated with system maintenance. Finally, when we have solutions to our 
research
-problems, we will use best solutions as examples in our algorithm proposals.
-
 \section{Thesis overview}
 This thesis is structured as follows. In next chapter, we give an overview of
 existing Peer-to-Peer approaches, algorithms and key differences. In chapter 
3, we
 address open problems in Peer-to-Peer domain and divide problems into three
 sub-categories. Chapter 4 gives an overview of Fenfire system. In chapter
-5, we evaluate existing Peer-to-Peer approaches with regard to Fenfire system 
and
-propose simple algorithms to perform data lookups in Fenfire's Peer-to-Peer 
enviroment. 
-Then, we discuss open issues and future work. In chapter 6, we present 
conclusions. 
+5, we evaluate existing Peer-to-Peer approaches with regard to Fenfire system, 
propose system
+model for Fenfire in Peer-to-Peer environment, present simple algorithms to 
perform data 
+lookups in Peer-to-Peer environment. Also, we discuss possible problems of 
using Fenfire
+in Peer-to-Peer environment. In chapter 6, we present conclusions and future 
work.
 
 
 \chapter{Peer-to-Peer architectures}
@@ -182,7 +179,7 @@
 \end{figure}
 
 Compared to ARPANET's Peer-to-Peer functionality, today's Peer-to-Peer systems
-are ad-hoc, i.e. peers join and leave the system constantly in a dynamic 
manner. This
+are ad-hoc, i.e., peers join and leave the system constantly in a dynamic 
manner. This
 fact constitutes challenging requirements for efficient construction and 
maintenance
 of the overlay network. Even more demanding tasks are how to perform efficient 
data
 lookup and maintain security in a varying distributed environment. The most 
popular
@@ -220,7 +217,7 @@
 Napster\footnote{We decided to include Napster in this section only because it 
has
 historical value (see previous section).} \cite{napsterurl}  was designed to 
to allow 
 people to share music. It was a hybrid Peer-to-Peer file-sharing system, i.e., 
the search 
-index was centralized and the distribution storage and serving of files was 
distributed. 
+index was centralized and the distribution of storage and serving of files was 
distributed. 
 Peers in the Napster network performed requests to the central directory 
server to find 
 other peers hosting desirable content. Since service requests was totally 
based on 
 centralized index, Napster didn't scale well because of constantly updated 
central 
@@ -246,12 +243,12 @@
 
 
 In Gnutella, each participating peer maintains local index of its own shared 
content. Also,
-each peer has a few connections to other peer, i.e. peer's \emph{neighbors}. 
Basic gnutella
+each peer has a few connections to other peer, i.e., peer's \emph{neighbors}. 
Basic gnutella
 data lookup works as follows: peer broadcasts a query request to its neighors, 
which in turn
 forwards the query to their neighbors. This leads in the situation where 
number of messages
 in the network can grow with $O(n^{2})$, where $n$ is the number of 
participating peers in the
 Gnutella network. To limit the amount of network traffic, Gnutella uses 
Time-To-Live-limited
-(TTL) flooding to distributed queries. Gnutella uses a Breadt-First-Traversal 
(BFS) with depth limit 
+(TTL) flooding to distributed queries. Gnutella uses a Breadt-First-Search 
(BFS) with depth limit 
 $T$ (e.g., 7), where $T$ is the system-wide maximum TTL of a message in hops. 
Therefore, only peers that 
 are TTL hops away from the query originator will forward the query or respond 
to the query. 
 In Gnutella network, search results are fast, because BFS sends queries to 
@@ -275,10 +272,10 @@
 the load on participating to the point, where it has to leave the network. 
 
 Lately, there has been done lot of research to improve Gnutella's data lookup 
efficiency 
-and scalability. Adamic et. all \cite{adamic99small}, 
\cite{adamic02localsearch}, 
+and scalability. Adamic et al. \cite{adamic99small}, 
\cite{adamic02localsearch}, 
 \cite{adamic01powerlawsearch} has been studied different random walk methods 
in power-law 
 networks\footnote{In power-law networks only a few peers have high number of 
neighbor 
-links and major of peers have low number of neighbor links.} and they have 
found that by 
+links and major of peers have low number of neighbor links.} and have found 
that by 
 instructing peers forwarding data lookups to select high degree peers, the 
performance of data lookup 
 increases signficantly. As a result, some of the most recent loosely
 structured Peer-to-Peer systems have adopted this method with some 
modifications
@@ -286,7 +283,7 @@
 \cite{kazaaurl}, \cite{jxtaurl}, \cite{jxtaoverview}, 
\cite{botros01jxtasearch},
 \cite{ganesan02yappers}.
 Figures \ref{fig:gnutella_overlay_supernodes} and 
\ref{fig:gnutella_overlay_cluster}
-illustrated two possible variations of power-law overlay networks. All the 
systems
+illustrates two possible variations of power-law overlay networks. All the 
systems
 share the property of that high degree peers maintain index of all other peers 
 they know about. However, it's not clear whether this algorithm is scalable or 
not, 
 as majority of the query request are sent only to the high degree peers, 
making 
@@ -309,7 +306,7 @@
 Previously presented improvements are only partial solutions. Obviously, more
 research is required to make data lookup of loosely structured approach more
 scalable and effective. More advanced techniques to improve data lookup of 
-loosely strcutured systems is presented in chapter 3.
+loosely structured systems are presented in chapter 3.
 
 
 \subsection{Sketch of formal definition}
@@ -339,18 +336,18 @@
 Symphony \cite{gurmeet03symphony}, SWAN \cite{bonsma02swan}, Tapestry 
 \cite{zhao01tapestry}, Viceroy \cite{malkhi02viceroy} and others 
\cite{freedman02trie}. 
 The biggest difference compared to loosely structured approach is that with 
tightly structured systems,
-it is now feasible to perform \emph{global} data lookups in overlay.
+it is now feasible to perform \emph{global} data lookups in the overlay.
 While there are significat differences among proposed systems, they all have 
in common
-that participating peers are assigned \emph{peer identifiers} from
-a large \emph{identifier space}. Furthermore, application-specific
+that \emph{peer identifiers} is assigned to participating peers from
+a large \emph{identifier space} by the overlay. Furthermore, 
application-specific
 data items are also assigned globally unique identifiers, \emph{keys}, 
 which are selected from the same identifier space. The form of identifier
 space differs between proposed systems. Circular identifier space (and 
variants) 
 is most widely used. For instance, Chord \cite{stoica01chord}, Koorde 
\cite{kaashoek03koorde}, 
 Pastry \cite{rowston01pastry}, SWAN \cite{bonsma02swan}, Tapestry 
\cite{zhao01tapestry}
 and Viceroy \cite{malkhi02viceroy} use a circular identifier space of $n$-bit 
integers modulo $2^{n}$. The
-value of $n$ varies among approaches. Again, CAN \cite{ratnasamy01can} uses a 
$d$-dimensional cartesian 
-to implement identifier space.
+value of $n$ varies among systems. Again, CAN \cite{ratnasamy01can} uses a 
$d$-dimensional cartesian 
+model to implement identifier space.
 
 Stoica et al.. \cite{balakrishanarticle03lookupp2p} have listed 
 four requirements for tightly structured overlays, which have to be 
@@ -365,7 +362,7 @@
 unique key (e.g., SHA-1 \cite{fips-sha-1}) is \emph{mapped} uniformly (e.g., 
using consistent
 hashing \cite{258660}) by the overlay to a existing peer in the overlay. Thus, 
tightly 
 structured overlay assigns a subset of all possible keys to every 
participating peer. 
-Specifically, each peer in tightly structured overlay maintains a 
\emph{routing table}, which 
+Also, each peer in tightly structured overlay maintains a \emph{routing 
table}, which 
 consists of identifiers and IP addresses of other peers in the overlay. 
Entries of routing
 table are peer's neighbors in the overlay network. Figure 
\ref{fig:structured_hashing} illustrates the 
 process of data to key mapping in tightly strucuted overlays.
@@ -395,7 +392,7 @@
 stabilization (like in Chord \cite{stoica01chord}) and backup links 
 (like in Pastry \cite{rowston01pastry}) \cite{balakrishanarticle03lookupp2p}. 
 However, in all previously schemes each 
-hop in the overlay shortens the distance between current peer working with 
query 
+hop in the overlay shortens the distance between current peer working with the 
data lookup 
 and the key which was looked up in the identifier space. 
 
 Skip Graphs and Swan employ a key space very similar to a tightly structured
@@ -410,7 +407,7 @@
 at the \emph{network} level layer. Peernet makes an explicit distinction 
 between peer identity and address, which is not supported by standard
 TCP/IP-protocols. Otherwise, PeerNet has the same performance properties
-as other tightly structured overlays, i.e. $O(\log{n})$ space required
+as other tightly structured overlays, i.e., $O(\log{n})$ space required
 for maintaining information about other peers in the system and 
 $O(\log{n})$ data lookup efficiency.
 
@@ -422,7 +419,6 @@
 In figure \ref{fig:structured_query}, we present overview of Chord's lookup 
process.
 On the left side of Chord's lookup process, we show the same data lookup 
process
 as binary-tree abstraction.  We can notice, that in each step, the distance 
between
-the query originator and the target in both methods is halved. Thus, the 
 locarithmic efficiency. 
 
 Kademlia \cite{maymounkov02kademlia}, Pastry \cite{rowston01pastry} and 
Tapestry 
@@ -470,8 +466,8 @@
 The basic operations are \texttt{join(groupIdentifier)}, 
\texttt{leave(groupIdentifier)},
 \texttt{multicast(message, groupIdentifier)},  \texttt{anycast(message, 
groupIdentifier)}.
 Participating peers may join and leave the group and send multicast messages to
-the group, or anycast message to a specific member of the group. DOLR's and 
CAST's
-have much in common.For instance, they both use network proximity techniques
+the group, or anycast message to a specific member of the group. DOLR and CAST 
abstraction
+have much in common. For instance, they both use network proximity techniques
 to optimize their operation in the overlay. Figure 
\ref{fig:Strucutred_lookup_using_DOLR_model}
  presents basic operation of DOLR abstraction. 
 
@@ -494,7 +490,7 @@
 \subsection{Sketch of formal definition}
 
 In this subsection we formalize tightly strucured overlay's main features. The 
model
-describes basic features of tightly structured overlay, i.e. identifiers, 
identifier
+describes basic features of tightly structured overlay, i.e., identifiers, 
identifier
 space and mapping function.
 
 Let $S$ be the aggregate of all services $s$ in system. Let $P$ be the 
aggregate of 
@@ -540,7 +536,7 @@
 (such as mapping of data items). 
 
 To end user, biggest difference between these systems is how data lookups are 
performed. Loosely
-structured systems provides much more richier and user friendly way of 
searching data as they
+structured systems provide much more richier and user friendly way of 
searching data as they
 have support for keyword search and fuzzy search. On the other hand, tightly 
structured systems support
 only exact key lookups as each data item is identified by globally unique keys.
 
@@ -657,14 +653,14 @@
 includes algorithms from two main approaches. However, majority of the 
algorithms 
 listed above belongs to tightly structured approach since there has been 
active 
 research being pursued towards tightly structured approach lately. List 
doesn't 
-include \emph{all} proposed Peer-to-Peer systems. Only the ones which already 
have 
+include \emph{all} proposed Peer-to-Peer algorithms. Only the ones which 
already have 
 been widely deployed in real-life, or the ones which may promising in the 
future's 
-Peer-to-Peer systems, are included in this thesis.
+Peer-to-Peer systems are included in this thesis.
  
 We decided to follow the guidelines from \cite{kaashoek03koorde} when
 measuring properties of different Peer-to-Peer systems. However, we dropped
 out fault tolerance and load balancing properties, since they are hard to 
measure
-in face of real life requirements. Additionally, we decided to include
+in face of real life requirements. Additionally, however, we decided to include
 the number of \emph{real} network connections for each peer in the overlay. 
 
 Here, we describe the listed properties of Peer-to-Peer algorihms:
@@ -886,16 +882,15 @@
 Since Napster \cite{napsterurl} and Gnutella \cite{gnutellaurl} was first time 
introduced 
 to public, researchers' main concern has been scalability problem of loosely 
structured 
 approach. However, people often misunderstand the scalability problem of 
loosely structured 
-approach; \emph{network} of loosely structured systems is scalable, but the 
\emph{query model} is not. 
+approach; \emph{network} of loosely structured systems is scalable, but the 
\emph{data lookup model} is not. 
 The main concern of tightly structured system is to make overlay's data lookup 
-routing more flexible againts hostile attacks. Another key problem in tightly 
structured 
-approach are the lack of keyword searches and support for heterogeneous peers.
+routing more flexible againts hostile attacks. Another key problems in tightly 
structured 
+systems are the lack of keyword searches and support for heterogeneous peers.
 
 To make Peer-to-Peer systems even more popular (e.g., in industry), 
Peer-to-Peer domain
 needs better infrastructures to deal with security issues. There has been done 
some
-research regarding anonymity, access control, data availability and data 
integrity. However,
-more research is needed specifically with redundancy, robustness and entity 
identification.
-
+research regarding anonymity, access control, data availability and data 
integrity but as
+we will observe, much more research work is required to solve security related 
issues.
 
 \section{Security problems in Peer-to-Peer}
 
@@ -909,7 +904,7 @@
 
 In Sybil attack model, hostile entity presents multiple 
 entities. Therefore, one hostile entity can control a large fraction of the 
Peer-to-Peer system. Optimal
-possible solution to Sybil attack would be that system could \emph{distinct} 
entities of system reliably. Unfortunately,
+possible solution to Sybil attack would be that system could \emph{distinct} 
entities of the system reliably. Unfortunately,
 currently there no realizable techiques for this task. Partial solutions for 
Sybil is attack is to replicate
 and fragment data randomly among several participating peer. However, both 
suggestions assume that two different 
 remote entities are actually different; Sybil attacks are still possible and 
therefore, would need centralized 
@@ -919,16 +914,16 @@
  
 In random fail-stop model, cited in \cite{naor03simpledht}, faulty peer is 
deleted from the Peer-to-Peer system.
 The reason for faultyness of peer can be a software failure, a hostile attack, 
or external threat such as virus or
-troijan. Closey related to fail-stop model is the Byzantine attack model 
+troijan. Closely related to fail-stop model is the Byzantine attack model 
 \cite{357176}. Byzantine model can been seen more seveve than fail-stop model 
as there are no restrictions over 
-the behaviour of faulty peers. Partial, practical solution for byzantine 
failures has been proposed by Castro et 
+the behaviour of faulty peers. Practical, but partial solution for byzantine 
failures has been proposed by Castro et 
 al \cite{296824}. 
 
 Spam generating attack is another known attack model againts Peer-to-Peer 
system. In Spam
 attack, hostile or faulty peer may produce false information of the data, or 
refuses/is not able to reply to requests. 
-Possible solution againts this attack is that peer should not trust to single 
entity. Instead peer should get 
+Possible solution againts 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 
methods requires more messages to be 
-sent to network increasing the load of system. However, if Spam attack is 
combined with Sybil attack, obviously 
+sent to network whilce increasing the load of system. 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 
 reliability. Naor et al. \cite{naor03simpledht} has proposed a partial 
solution againts Spam attack with 
 \emph{faulty} peers (not hostile).
@@ -961,8 +956,8 @@
 data in rather \emph{static} computing systems, such as in the Internet. 
However, in Peer-to-Peer 
 network, the problem of key based security mechanism is the maintenance of the 
keys as participating
 peer constantly join and leave the system. Specifically, the distribution of 
key changes comes an essential
-problem in ad hoc enviroments. These include revokation of keys and new key 
distribution. Also, the scenario
-in which hostile peers are present has to be addressed.
+problem in ad hoc enviroments. These include revokation of keys and new key 
distribution in hostile 
+environment.
 
 ConChord \cite{ajmani02conchord} is the first Peer-to-Peer system which has a 
support for PKI based
 security infrastructure. Unfortunately, ConChord is in early in development 
and lacks of important
@@ -978,14 +973,14 @@
 
 \subsection{Anonymity}
 
-According to \cite{dingledine00free}, there exists several kinds of anonymity. 
Author-anonymity is form
+According to \cite{dingledine00free}, there exists several kinds of anonymity. 
Author-anonymity is a form
 of anonymity in which no one can link author to a specific document. In 
publisher-anonymity system,
 no one is able to link publisher to a specific document. Reader-anonymity 
means that a specific
 document cannot be linked to document's readers. This form of anonymity 
protects the privacy of a
-users of the system. Furthermore, in peer-anonymity means that no peer can be 
linked to a specific document, i.e.
+users of the system. Furthermore, peer-anonymity means that no peer can be 
linked to a specific document, i.e.,
 no one is able to determine the peer, where document was originally published. 
Document-anonymity
-means that peer doesn't know which data it is currently hosting. Finally, 
query-anonymity refers is form
-of document-anonymity; when other peers performs data lookups, peer doesn't 
know which data it servers
+means that peer doesn't know which data it is currently hosting. Finally, 
query-anonymity is a form
+of document-anonymity; when other peers performs data lookups, peer doesn't 
know which data it serves
 to the data lookup originators. As the authors cite, some of forms of 
anonymity may imply each other and
 possible issues are one area of future work.
 
@@ -993,11 +988,11 @@
 level layer \cite{tarzan:ccs9} and at application level layer 
\cite{reiter98crowds}, \cite{mixminionurl}.
 Research on anonymity outside of Peer-to-Peer context have been done also 
\cite{352607}, \cite{293447}.
 
-Obviously, providing several types of anonymity, anonymity often conflicts 
with other key properties of
-Peer-to-Peer system. Let's consider anonymity and efficient data lookup. In 
efficient lookup, we must know
+Obviously, providing several types of anonymity, it often conflicts with other 
key properties of
+Peer-to-Peer system. Let's consider anonymity and efficient data lookup. In 
efficient data lookup, we must know
 the peers responsible to 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, i.e. \emph{pseudonym} which is a partial form of 
anonymity. For instance, pseudonym can used for 
+mentioned situations, such as \emph{pseudonym} which is a partial form of 
anonymity. For instance, pseudonym can used for 
 addressing peer-anonymity by providing anonymous-like identifiers to peers 
(e.g., peer identifiers of tightly 
 structured system).
 
@@ -1011,15 +1006,15 @@
 of anonymity
 
 Even if many existing Peer-to-Peer systems are able to provide some of the 
types of anonymity, there is no
-such a system which is able to provide all kinds of anonymity as listed above. 
Furthermore, 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 requires more 
research work.
 
 
 \subsection{Access control}
 
-Any distributed computing system must support different levels of access 
control. For instance, we may
-want to restrict the accessibility of data to only limited amount of 
participating peers. Peer-to-Peer 
-systems doesn't support working and distributed access control scheme. 
Moreover, 
+Any distributed computing system must support different levels of access 
control. For instance, in Peer-to-Peer
+system, we may want to restrict the accessibility of data to only limited 
amount of participating peers. Yet, Peer-to-Peer 
+systems doesn't have working and distributed access control scheme. Moreover, 
 there has been a lot of violation of copyright laws by users of Peer-to-Peer 
filesharing systems. As a 
 consequence, some lawsuits has been created againts the companies how have 
build popular file-sharing programs.
 
@@ -1035,7 +1030,7 @@
 proposed in \cite{sit02securitycons}, distributed and secure peer identifier 
assignment 
 \cite{castro02securerouting}, \cite{clarke00freenet} and self-certifying data 
using cryptographic 
 content hashes (e.g., SHA-1 \cite{fips-sha-1}). Identification of hostile 
entities is essential in tightly structured 
-approach, in which fundamental (and implicit) assumption is that there is 
random, uniform distribution 
+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 
@@ -1045,12 +1040,12 @@
 puzzles \cite{juels99clientpuzzles}.
 
 In the end, none of previously mentioned solutions are able to identify 
hostile entities in practical,
-efficient way. More research is required to solve this problems.
+efficient way. More research is required to solve these problems.
 
 
 \subsection{Secure query routing}
 
-Much work has been done on secure routing, especially in tightly structured 
systems. In 
+Much work has been done on secure routing, especially related to tightly 
structured systems. In 
 \cite{castro02securitystructured} and \cite{castro02securerouting}, authors 
suggests the usage
 of constrained routing tables and diverse routes, and detection of faults 
during query routing.
 Additionally, authors present a important aspect of tightly structured 
approach with regard
@@ -1062,7 +1057,7 @@
  approach is not very efficient, since proposals create a 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 
to secure routing table 
 maintenance, but their solution seems to have to 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
@@ -1071,27 +1066,28 @@
 Aspnes et al. in \cite{aspnes02faultrouting} and Kaashoek et al.l in 
\cite{kaashoek03koorde} formally 
 prove the lower and upper bounds for space requirements of locating a specific 
date item in 
 Peer-to-Peer system. They show that to provide high degree of fault tolerance 
and efficiency, each 
-participating peer must maintain $O(\log{n})$ neighbors. 
+participating peer must maintain average of $O(\log{n})$ neighbors. 
 
 Fiat et al. in \cite{fiat02censorship}, 
\cite{saia02dynamicfaultcontentnetwork} and Datar in \cite{datar02butterflies}  
 describe tightly structured overlay with analytical results in the presence of 
hostile entities. However,
 none of these proposals doesn't address an efficient, dynamic tightly 
structured overlay and multiple rounds
-of hostile attack. Also, above mentioned propsals are not very efficient. In 
\cite{fiat02censorship}, each node 
+of hostile attack. Also, above mentioned proposals are not very efficient. In 
\cite{fiat02censorship}, each node 
 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}, 
\cite{gavoille01routing} list several open problems
-regarding routing in distributed networks. Obviously, more research is 
required in order to provde secure
+regarding routing in distributed networks. Obviously, more research is 
required in order to provide secure
 data lookup routing possible in Peer-to-Peer networks.
 
 
 \subsection{Other security threats}
 
-Ross Lee graham lists several external threats againts Peer-to-Peer networks 
\cite{grahamp2psecurity}. The list 
-includes viruses, trojans and bugs in Peer-to-Peer software. Currently, there 
are not even partial solutions
+Ross Lee graham lists several external threats againts Peer-to-Peer networks 
\cite{grahamp2psecurity}. Most important, t
+he 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 redundancy againts 
external threats is unknown. 
 The reason for this is that there are no experiences on these kinds of 
attacks. Possible solution 
-would be distributed anti-virus software, but much more intensive research is 
required for solve these problems.
+would be distributed anti-virus software, but much more intensive research is 
required until
+this kind of solution would be applicable. 
 
 
 
@@ -1106,11 +1102,11 @@
 especially with loosely structured approach. In addition to ''super-peer'' 
method presented in chapter
 2, there has been other improvements also. 
 In iterative deepening 
-\cite{yang02improvingsearch}, multiple breadt-first searches are initiated
+\cite{yang02improvingsearch}, multiple BFS searches are initiated
 with successively larger TTL depth limits, until either the query is 
satisfied, 
 or the maximumum depth $D$ has been reached. To perform a data lookup, query
-originator starts a flood with small TTL value. If the search is not succesful,
-the query originator increases the TTL value and performs another flood. This 
+originator starts a data lookup with small TTL value. If the search is not 
succesful,
+the query originator increases the TTL value and performs another data lookup. 
This 
 process is repeated until the desired data is found or maximumum depth $D$ 
 has been reached. Expanding ring, proposed by Shenker et al.., 
\cite{lv02searchreplication}, 
 is similar to iterative deepening techique. With these techniques, search 
@@ -1120,7 +1116,7 @@
 BFS in way that peer selects neighbors with many quality results
 may be reached, thereby maintaining the the quality of costs and decreasing 
the amount
 of messages sent to network. Alpine \cite{alpineurl} and NeuroGrid 
\cite{joseph02neurogrid} 
-are Peer-to-Peer system use somewhat similar method when performing data 
lookups.
+are Peer-to-Peer system which use somewhat similar method when performing data 
lookups.
 
 Local indices \cite{yang02improvingsearch} is one variation of active caching. 
 In this scheme, each peer maintains an index over the data of all nodes within 
@@ -1136,7 +1132,7 @@
 random walk approach can be done more effective by introducing
 multiple ''walkers''. Freenet \cite{clarke00freenet} Peer-to-Peer system uses 
 random walk searches in query lookups. Indeed, Freenet's query resembles
-depth-first traversal and peers' routing tables are dynamically built
+Depth-First-Search (DFS) and peers' routing tables are dynamically built
 using caching. This is an outcome of Freenet's main design priciples, 
 i.e., anonymity. Additional improvements to Freenet's data lookup using
 ''small-world phenomenon'' has been proposed by Zhang et al.. 
\cite{zhang02using}.
@@ -1147,7 +1143,7 @@
 peers try to choose routing-tables entries refering 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 a 
advanced heuristics for
+Pastry \cite{rowston01pastry} and Tapestry \cite{zhao01tapestry} have advanced 
heuristics for
 proximity based routing. Additionally, most recent version of Chord uses 
proximity based 
 routing inspired by Karger and Ruhl \cite{karger02findingnearest}. Skipnet 
\cite{harvey03skipnet1} 
 uses combination of proximity and application level overlay routing when 
performing data 
@@ -1167,25 +1163,26 @@
 structured systems are able 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 in problem with tightly structured approach is the fact that tightly 
structured algorihms
-performs data lookups based on a globally unique identifier. Quite recent 
study has been focused 
+The main problem with tightly structured approach is the fact that tightly 
structured algorihms
+performs 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}. Authors
 argue, that it is possible to implement Peer-to-Peer Web-like search with 
certain radical compromises. 
-First, Peer-to-Peer search enginge may need to decrease result quality in 
order make searching more
+First, Peer-to-Peer search engine may need to decrease result quality in order 
make searching more
 efficient. Second, Peer-to-Peer systems must observe better the properties of 
underlying network for
 better performance. 
 
-Some studies have been concentraded on SQL-like queries \cite{harren02complex}
-in tightly structured overlays. Another approaches includes adaption of data 
lookup model of loosely 
+Some studies have been concentrated on SQL-like queries \cite{harren02complex}
+in tightly structured overlays. Another approaches include adaption of data 
lookup model of loosely 
 structured approach into tightly structured systems 
\cite{ansaryefficientbroadcast03}, \cite{chord:om_p-meng}.
 Additional studies include additional layer upon overlay network 
\cite{kronfol02fasdsearch}, 
 \cite{joseph02p2players} and range queries \cite{andrzejak02rangequeries}.
 
 Many techniques have been developed in order to provide more efficient search 
indexing. As 
-studies queries follow Zipf-like distributions\footnote{Zipf distribution is a 
variant of power-law function. 
+several studies show, the popularity of queries in the Internet follow 
Zipf-like 
+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.} \cite{breslau98implications} caching and precomputation
+$a$ is close to unity.} (e.g., \cite{breslau98implications}), caching and 
precomputation
 can be done for optimizting search indices \cite{li03feasibility}. Regular 
compression algorithms,
 Bloom filters \cite{362692}, vector space models 
\cite{CuencaAcuna2002DSIWorkshop} and view 
 trees \cite{Bhattacharjee03resultcache} can be used for even better 
optimizations. Authors 
@@ -1223,38 +1220,38 @@
 more efficient analytical tools for modelling complex Peer-to-Peer system. 
 
 Some research has been done with regard to load balancing properties of 
tightly structured
-overlays. Byers et al.. suggest "power of two choices" whereby an item is 
stored at the less loaded 
-of two (or more) random alternatives \cite{byers03dhtbalancing}. Rao et al.. 
uses virtual servers
+overlays. Byers et al. suggest "power of two choices" whereby an item is 
stored at the less loaded 
+of two (or more) random peer alternatives \cite{byers03dhtbalancing}. Rao et 
al. uses virtual servers
 to control load balance in Peer-to-Peer systems \cite{rao03loadbalancing}. 
Their work rests on
-idea which was originally introduced by Chord system.
+idea which was originally introduced by Chord \cite{stoica01chord} system.
 
 Also, query and routing hotspots may be an issue in tightly structured 
overlays \cite{ratnasamy02routing}. 
 Hotspots happen, when 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 
+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.
 
-An implicit assumption of almost every tightly structured system is that there 
is random, uniform 
+As mentioned before, an implicit assumption of almost every tightly structured 
system is that there is random, uniform 
 distribution of peer and key identifiers. Even if participating peers are 
extremely heterogeneous in
 face of computing power, or network bandwidth, data items are distributed 
uniformly. Clearly, this
-a serious problem of tightly structured overlays , since measurement study by 
Saroiu et al.. shows 
-that there extreme heterogeneity among participating peers in already deployed 
Peer-to-Peer systems.
-\cite{saroiu02measurementstudyp2p}. Symphony seems to be the first tightly 
structured overlay system 
-which support hetergeneity. However, Zhao et al.. have proposed a secondary 
layer a top of structured overlay
+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 
+systems \cite{saroiu02measurementstudyp2p}. Symphony seems to be the first 
tightly structured overlay system 
+which support hetergeneity. Zhao et al. have proposed a secondary layer a top 
of structured overlay
 to support hetergeneity better \cite{zhao02brocade}. 
 
-Research has been done on self-organization. Ledlie et al.. propose techniques 
for forming and maintaining
+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
 participating peers would create multiple hierarchical groups; it's 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 to Peer-to-Peer environment. More promising 
work has been done by Rowston et al.
 in \cite{rowston03controlloingreliability}. Authors propose techiques for 
self-tuning, dealing with
 uncommon conditions (e.g., network partition and high failure rates). 
Moreover, authors arque that
-these techniques, the concerns over the tightly structured overlay maintenance 
costs are no more
+with these techniques, the concerns over the 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..
+Finally, little research has been done regarding self-monitoring and data 
availability. Zhang et al.
 describe a arbitrary data structure on top of tightly structured overlay 
\cite{zhang03somo}. They
-call their proposal as \emph{data overlay}, since it support several 
fundamental data structures.
+call their proposal as \emph{data overlay}, since it supports several 
fundamental data structures.
 Authors use this data overlay to build Self-Organized Metadata Overlay (SOMO), 
which can be used
 for monitoring health of tightly structured overlay. Fault tolerance of SOMO 
itself is currently
 unknown. 
@@ -1266,9 +1263,9 @@
 
 \subsection{Programming guidelines and benchmarks}
 
-All existing Peer-to-Peer systems have rather different interfaces even they 
common points and 
+All existing Peer-to-Peer systems have rather different interfaces even they 
have common points and 
 components. More important, all existing Peer-to-Peer systems incompatible 
with each other. One
-of the most important area of future research is to create common programming 
abstractions, i.e.
+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
 guidelines. This list includes \cite{zhao03api}, \cite{frise02p2pframework}, 
\cite{babaoglu02anthill}.
@@ -1284,10 +1281,10 @@
 
 Somewhat surprisingly little research has been in this area, especially when 
considering 
 the possible impact of this \emph{unwanted socical behaviour} to performance 
of Peer-to-Peer 
-system. Problem is addressed by Golle et al.. \cite{golle01incentivesp2p}. 
Some 
+system. Problem is addressed by Golle et al. \cite{golle01incentivesp2p}. Some 
 research has been focused on semantic properties of the overlay in order to 
increase 
-cooperation among participating peers \cite{crespo02semanticoverlay}. 
Ramanathan et al.. 
-\cite{ramanathan02goodpeers} and Bernstein et al.. \cite{bernstein03selection} 
use 
+cooperation among participating peers \cite{crespo02semanticoverlay}. 
Ramanathan et al. 
+\cite{ramanathan02goodpeers} and Bernstein et al. \cite{bernstein03selection} 
use 
 empirical metrics and decision trees when teaching peers to make better 
decisions
 when contacting other peers in Peer-to-Peer system. Alpine \cite{alpineurl} is 
an example of
 Peer-to-Peer system, which uses empirical metrics for peer selection.
@@ -1297,7 +1294,7 @@
 
 Very little research has been done on simulating the \emph{global} 
Peer-to-Peer system. Presumably, this
 is due to complex nature of Peer-to-Peer system, which makes comprehensive 
simulations very 
-diffucult. Floyd et al.. has been studying the simulation of the Internet in 
\cite{504642}. Authors
+diffucult. Floyd et al. has been studying the simulation of the Internet in 
\cite{504642}. Authors
 state that simulating the Internet is very challenging task, because of 
Internet's heterogeneity
 and rapid change. Obviously, these factors exist also in Peer-to-Peer system 
even with higher
 rates.
@@ -1310,10 +1307,9 @@
 \section{Summary}
 
 In this section we summarize open problems in Peer-to-Peer systems. All open 
problems entries 
-listed in this section are not necessarily mentioned in the previous sections. 
This is because
-we discussed only the most significant problems earlier. Problems listed here 
are variations
-of previously mentioned problems, or otherwise related to them. For each 
entry, there is brief
-description of the problem, possible solutions and comments respectively.
+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 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} 
 we list open problems related to security; in table 
\ref{table_performanceusability_problems_Peer-to-Peer}, 
@@ -1648,7 +1644,7 @@
 
 \chapter{Fenfire hypermedia system}
 
-In this chaper we give an overview of Fenfire system. We also 
+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, 
 Fenfire's software module, which is an essential part of Fenfire's 
Peer-to-Peer 
 functionality. 
@@ -1657,9 +1653,9 @@
 
 Fenfire project \cite{fenfireurl} is an effort to build a distributed, 
hyperstructured user 
 interface system. Fenfire is free software and it is licenced under GNU L-GPL. 
Fenfire's main goal 
-is to implement xanalogical storage model \cite{ted-xu-model}. Fenfire was 
formely also an implementation 
+is to implement xanalogical storage model \cite{ted-xu-model}. Fenfire was 
formely also a implementation 
 of the ZigZag\texttrademark --structure, which was originally invented 
-by Ted Nelson. Now, however, Fenfire uses Resource Description Framework 
\cite{w3rdfurl}
+by Ted Nelson. Now, however, Fenfire uses Resource Description Framework (RDF) 
\cite{w3rdfurl}
 for representing internal data structures and their relationships. 
 
 Fenfire is high modular software system. It consists of several independent 
software modules:
@@ -1673,13 +1669,13 @@
 \item \textbf{LibVob}: graphic library used for creating navigation interfaces 
in complex data views
 \end{itemize}
 
-In this thesis, we focus on Storm and Xu-Storm modules, since they are the 
foundation of Fenfire's 
+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 modules.
+Storm and Alph software modules.
 
 \section{Xanalogical model}
 
-Xanalogical storage \cite{nelson99xanalogicalneeded} is different kind of 
model for 
+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 
 \emph{characters}. Indeed, each character in xanalogical storage model has a
@@ -1706,7 +1702,7 @@
 different data contents. By using this mechanism, system implementing 
xanalogical model
 is able to show all data content that share same fluid media with current data 
content
 (e.g., all documents containing current document's text). Figure 
\ref{fig:xanalogical_model}
-illustrates xanalogical model used with documents, text and characters.
+illustrates xanalogical storage model with documents, text and characters.
 
 
 \begin{figure}
@@ -1719,21 +1715,21 @@
 
 \section{Storm}
 
-In this section, we will give an brief overview of Storm design. More 
information can be found
+In this section, we will give a brief overview of Storm design. More 
information can be found
 from recent publications: for general discussion about Fenfire in Peer-to-Peer 
environment, 
 see \cite{lukka02freenetguids}, and for detailed Storm design, see 
\cite{fallenstein03storm}.
 
 Storm (for \emph{STORage Module}) is a software module, which is used in 
Fenfire for
-implementing basic data storage operations. Storm stores all data as 
\emph{blocks}, which
+data storage operations. Storm stores all data as \emph{blocks}, which
 are immutable byte sequences. SHA-1\footnote{SHA-1 is considered a collision 
free 
 hash function. Therefore, it is very unlikely that two different Storm data 
blocks 
 would have same identifier.} cryptographic content hash \cite{fips-sha-1} is 
used
 for creating locatiotion-independent, globally unique identifiers for blocks. 
Additionally,
-SHA-1 \cite{fips-sha-1} is used for verifying the integrity of scroll blocks. 
Storm
+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 Storm blocks are 
\emph{immutable} as
 any change to the byte sequence would the change block's hash value, i.e., 
unique 
-identifier. This mechanism creates a basis for implementing xanalogical model 
in our
-Fenfire system. Figure \ref{fig:storm_model} illustrated simplified Storm 
storage model.
+identifier. This mechanism creates a basis for implementing xanalogical model 
in 
+Fenfire system. Figure \ref{fig:storm_model} illustrates simplified Storm 
storage model.
 
 \begin{figure}
 \centering
@@ -1748,9 +1744,9 @@
 we discuss only pointers as they are part of the thesis' research problems. 
 More information about diffs can be found from \cite{fallenstein03storm}.
  
-Pointer is a updatable reference to scroll block. In practice, pointer is a 
-random string created automatically by Storm \cite{benja02urn5}, associated 
-with a collection of \emph{pointer blocks}. Each pointer block has a single 
+Pointer \cite{benja02urn5} is an updatable reference to Storm data block, 
i.e., Storm scroll block. 
+In practice, pointer is a random string created automatically by Storm , 
+associated with a collection of \emph{pointer blocks}. Each pointer block has 
a single 
 target for the pointer. In figure \ref{fig:storm_model}, we present overal 
 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 
@@ -1771,10 +1767,11 @@
 
 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. Then, we define Fenfire's objectives and special needs in 
Peer-to-Peer
-environment. Finally, we evaluate different peer-to-peer approaches with 
regard 
-to Fenfire, and propose initial algorihms for obtaining Fenfire specific data 
-from Peer-to-Peer overlay network.  
+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, present simple algorithms to 
perform data 
+lookups in Peer-to-Peer environment. Also, we discuss possible problems of 
using Fenfire
+in Peer-to-Peer environment
 
 
 \section{Problem overview}
@@ -1810,8 +1807,8 @@
 \cite{lukka02freenetguids}. Authors' work is mainly based on insight of 
implementing
 xanalogical model in Peer-to-Peer enviroment with globally unique identifiers. 
Lukka et al.
 use Freenet \cite{clarke00freenet} as a example Peer-to-Peer system supporting 
-globally unique identifiers. This thesis presented here extends their work by 
-evaluating different Peer-to-Peer approaches more extensively to Fenfire's 
needs.
+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 
@@ -1833,7 +1830,7 @@
 is limited to certain area of overlay\footnote{The area depends on where the 
query
 originator is located in the overlay.}.
 
-For Fenfire's special needs for \emph{locating} data, the most important 
advantage of 
+For Fenfire's special needs for \emph{locating} data, an important advantage 
of 
 tightly structured approach over loosely structured approach is that tightly 
 structured systems use location-independent, globally unique identifiers for 
 identifying data in the system. Indeed, this 
@@ -1843,7 +1840,8 @@
 Currently, Domain Name System (DNS) \cite{rfc1101} is 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{semantic free}. To summarize, these aspects may be the most important 
features 
+\emph{semantic free}. Finally, with tightly stuctured 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.
 Thus, we see the tightly structured approach the best alternative to locate 
data in Peer-to-Peer
 environment.
@@ -1910,17 +1908,17 @@
 
 \subsection{Algorithms}
 
-We use DOLR model of tightly of structured approach, i.e. each participating 
peer hosts 
+We use DOLR abstraction of tightly of structured approach, i.e. each 
participating peer hosts 
 the data and overlay maintains only the \emph{pointers} to the data. We 
descided to use DOLR in our
 model, since DOLR systems locate date without specifiying a storage policy 
explicity \cite{rhea03benchmarks}. 
-DHT based storage systems, such as CFS \cite{dabek01widearea} and PAST 
\cite{rowstron01storage}, have
+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 able to store relative great amount of data with key/value pair, 
assigned randomly by 
 mapping function of the overlay. Additionally, these systems wastes both 
storage and bandwidth, and
 are sensitive to certain attacks (e.g., DDoS attack).
 
 In the following subsections we assume that we know the structure of 
-''virtual file'' before hand, i.e. when assmbling a ''virtual file'', we know 
all Storm 
+''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 
 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 techique for 
identifying invidual entities, or
@@ -1931,7 +1929,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} algorihm 
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.
 
 
@@ -1939,9 +1937,9 @@
 \item Data lookup with a given identifier of Storm scroll block.
 \begin{enumerate}
 \item Submit query using scroll block's identifier.
-\item Repeat until hosting node is found: each peer forwards the query to a 
closer peer which hosts the given scroll block identifier.
+\item Repeat until hosting peer is found: each peer forwards the query 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 node to return the scroll block.
+\item Query originator requests hosting peer to return the scroll block.
 \end{enumerate}
 \end{itemize}
 
@@ -1953,10 +1951,10 @@
 \begin{itemize}
 \item Data lookup with a given pointer random string returning most recent 
scroll block.
 \begin{enumerate}
-\item Query originator locally compute a hash for given urn-5 random string.
-\item Repeat until hosting node is found: each peer forwards the query to a 
closer peer which hosts the given hash of pointer random string.
+\item Query originator locally compute a hash for given pointer random string.
+\item Repeat until hosting peer is found: each peer forwards the query 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 node to return the scroll block.
+\item Query originator requests hosting peer to return the scroll block.
 \end{enumerate}
 \end{itemize}
 
@@ -1964,15 +1962,15 @@
 \item Data lookup with a given pointer random string returning scroll block(s) 
for a given date and time range.
 \begin{enumerate}
 
-\item Query originator locally compute a hash for given urn-5 random string.
-\item Repeat until hosting node is found: each peer forwards the query to a 
closer peer which hosts the given hash of pointer random string.
+\item Query originator locally compute a hash for given pointer random string.
+\item Repeat until hosting peer is found: each peer forwards the query 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 node to return the scroll block.
+\item Query originator requests hosting 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 urn-5 is known.
+in a tightly structured overlay using DOLR method, where pointer random string 
is known.
 
 Each of these algortihms can locate Fenfire related data in $\Theta(\log{n})$ 
time:
 $O(\log{n})$ time for query routing to pointer peer and constant time for 
@@ -1983,14 +1981,14 @@
 \begin{figure}
 \centering
 \includegraphics[width=11cm, height=8cm]{storm_query_blockid.eps}
-\caption{Locating owner peer for a given block ID}
+\caption{Locating owner peer for a given Storm block identifier}
 \label{fig:storm_query_blockid}
 \end{figure}
 
 \begin{figure}
 \centering
 \includegraphics[width=11cm, height=8cm]{storm_query_urn5.eps}
-\caption{Locating owner peer for a given urn-5}
+\caption{Locating owner peer for a given pointer random string}
 \label{fig:storm_query_urn5}
 \end{figure}
 
@@ -1998,12 +1996,12 @@
 \subsection{Problems}
 
 Perhaps the most biggest issue in Peer-to-Peer systems is non-maturity of
-secure techologies. For instance online entities cannot be identified 
+secure techologies. 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 user is able to verify the correctness
 of the search results, and how do we know which one is the 
-correct Storm scroll block ? Spam attack is variation of previously
+correct Storm scroll block ? 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 do we are able to know if this was a spam attack, or the
 data really no exist in the system ? Another problem related to Fenfire's 
@@ -2012,15 +2010,14 @@
 authenticity of data. Obviously, optimal solution to all security issues would 
 be that digital signatures are included to every message sent in the system. 
 However, these problems are not only limited to Fenfire, it concerns all 
-Peer-to-Peer based computer systems. We believe these problem is solved in a 
-near future as very intesive research is carried out in Peer-to-Peer field.
+Peer-to-Peer based computer systems.
 
 \chapter{Conclusions and future work}
 
 In this thesis, we have reviewed existing Peer-to-Peer approaches, algorithms 
and
 their properties. Currently, two main Peer-to-Peer overlay approaches
-exist: loosely and tightly structured ovelrays. We discussed approaches'
-differences, disadvantages and advantages.
+exist: loosely and tightly structured overlays. We have discussed differences, 
+disadvantages and advantages of both approaches.
 
 After that, we summarized open problems in Peer-to-Peer networks. Specifically,
 we divided open problems into three sub-categories: security related problems,
@@ -2030,18 +2027,18 @@
 solve open problems.
 
 Then, we focused our attention to Fenfire system. First, we gave a brief
-overview of Fenfire and xanalogical model. We also discussed Storm and urn-5, 
-which are essential parts of Fenfire's Peer-to-Peer functionality.
+overview of Fenfire and xanalogical model. We also described Storm, 
+which is an essential part of Fenfire's Peer-to-Peer functionality.
 
 In last chapter, we evaluated existing Peer-to-Peer approaches with regard
 to Fenfire's needs. We proposed, that tightly structured approach is the
-best alternative to our needs. First, Storm, xanalogical
-model and tightly structured approach all use global unique identifiers
-for identifying data. Second, our Storm design uses Semantic-Free references
+best alternative to our needs for the following reasons. First, Storm, 
xanalogical
+model and tightly structured systems use global unique identifiers
+for identifying data. Second, our Storm design uses semantic-free references
 for locating data in distributed networks. As the authors of 
\cite{balakrishnan03semanticfree},
 we also observe that tightly structured overlays provide general purpose
 interface to next-generation reference resolution services. Second, by using 
-DOLR method of tightly structured overlay, we can minimize the the lack 
+DOLR abstraction of tightly structured overlay, we can minimize the the lack 
 of locality in tightly structured overlays. Finally, we believe that issues 
 related to tightly structured overlays are solved in near future, because of
 wide and intensive co-operation among research groups.
Index: gzz/Documentation/misc/hemppah-progradu/progradu.bib
diff -u gzz/Documentation/misc/hemppah-progradu/progradu.bib:1.98 
gzz/Documentation/misc/hemppah-progradu/progradu.bib:1.99
--- gzz/Documentation/misc/hemppah-progradu/progradu.bib:1.98   Wed Mar  5 
09:56:30 2003
+++ gzz/Documentation/misc/hemppah-progradu/progradu.bib        Thu Mar  6 
10:12:33 2003
@@ -295,7 +295,7 @@
 
 %Method which e.g. Pastry and Tapestry are build on
 @inproceedings{plaxton97accessingnearby,
-        author = {C. Greg Plaxton and Rajmohan Rajaraman and Andr?a W. Richa},
+        author = {C. Greg Plaxton and Rajmohan Rajaraman and Andréa W. Richa},
         title = {Accessing nearby copies of replicated objects in a 
distributed environment},
         booktitle = {Proceedings of the ninth annual ACM symposium on Parallel 
algorithms and architectures},
         year = {1997},
@@ -381,7 +381,7 @@
 
 % Routing methhods to be used in p2p env.
 @inproceedings{aspnes02faultrouting,
-       author = {James Aspnes and Zo? Diamadi and Gauri Shah},
+       author = {James Aspnes and Zoë Diamadi and Gauri Shah},
        title = {Fault-tolerant routing in peer-to-peer systems},
        booktitle = {Proceedings of the twenty-first annual symposium on 
Principles of distributed computing},
        year = {2002},
@@ -1205,7 +1205,7 @@
 
 %Tangler publishing system
 @inproceedings{502002,
-       author = {Marc Waldman and David Mazi?res},
+       author = {Marc Waldman and David Mazières},
        title = {Tangler: a censorship-resistant publishing system based on 
document entanglements},
        booktitle = {Proceedings of the 8th ACM conference on Computer and 
Communications Security},
        year = {2001},
@@ -1419,7 +1419,7 @@
        title = "Self-Organization in Peer-to-Peer Systems",
        author = "Jonathan Ledlie and Jacob Taylor and Laura Serban and Margo 
Seltzer",
        booktitle = {In Proceedings of the 10th ACM SIGOPS European Workshop},
-       location = {Saint-?milion, France},
+       location = {Saint-Émilion, France},
        month = {September},    
        year = {2002},
        url = {http://www.eecs.harvard.edu/~jonathan/p2p/sigops02abstract.pdf}
@@ -1603,7 +1603,7 @@
 }
 
 @misc{benja02urn5,
-       author = {University of Jyv?skyl? Hyperstructure Group, Benjamin 
Fallenstein},
+       author = {University of Jyväskylä Hyperstructure Group, Benjamin 
Fallenstein},
        title = {urn-5 namespace registration},
        month = {Aug},
        year = {2002},
@@ -1819,7 +1819,7 @@
 
 %Schema based access control
 @misc{nejdl03accesscontrol,
-       author = {Wolfgang Nejdl and Wolf Siberski and Martin Wolpers and 
Alexander L?ser},
+       author = {Wolfgang Nejdl and Wolf Siberski and Martin Wolpers and 
Alexander Löser},
        title = {Information Integration in Schema-Based Peer-To-Peer Networks},
        booktitle = {Submitted at the 15th Conference On Advanced Information 
Systems Engineering(CAiSE)},
        year = {2003},
@@ -1932,7 +1932,7 @@
 
 
 @inproceedings{fallenstein03storm,
-       author = {Toni Alatalo and Benja Fallenstein and Hermanni Hyyti?l? and 
Tuomas Lukka},
+       author = {Benja Fallenstein and Toni Alatalo and  and Hermanni Hyytiälä 
and Tuomas Lukka},
        title = {Storm: Supporting data mobility though location-independent 
identifiers},
        booktitle = {Submitted for publication (The fourteenth conference on 
Hypertext and Hypermedia (Hypermedia '03))},
        year = {2003}   
@@ -1975,7 +1975,7 @@
         for Digital Audio and Video (NOSSDAV 2001)",
         month = "June",
         year = "2001",  
-        url = 
"http://www.cs.berkeley.edu/~ravenben/publications/pdf/bayeux.pdf";
+        url = 
{http://www.cs.berkeley.edu/~ravenben/publications/pdf/bayeux.pdf}
 }
 
 @misc{fenfireurl,
@@ -2077,7 +2077,7 @@
 }
 
 @inproceedings{338634,
-       author = {Erik D. Demaine and Alejandro L?pez-Ortiz and J. Ian Munro},
+       author = {Erik D. Demaine and Alejandro López-Ortiz and J. Ian Munro},
        title = {Adaptive set intersections, unions, and differences},
        booktitle = {Proceedings of the eleventh annual ACM-SIAM symposium on 
Discrete algorithms},
        year = {2000},




reply via email to

[Prev in Thread] Current Thread [Next in Thread]