[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/27 05:13:06

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

Log message:
        Updates

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/Documentation/misc/hemppah-progradu/masterthesis.tex.diff?tr1=1.198&tr2=1.199&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/Documentation/misc/hemppah-progradu/storm_pointerblock_creation.eps.diff?tr1=1.4&tr2=1.5&r1=text&r2=text

Patches:
Index: gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
diff -u gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.198 
gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.199
--- gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.198      Thu Mar 
27 02:04:16 2003
+++ gzz/Documentation/misc/hemppah-progradu/masterthesis.tex    Thu Mar 27 
05:13:04 2003
@@ -19,7 +19,7 @@
 %***********************
 \title{Fenfire in Peer-to-Peer Environment}
 
-\translatedtitle{Fenfire vertaisverkko ympäristössä}
+\translatedtitle{Fenfire vertaisverkkoympäristössä}
 
 \author{Hermanni Hyytiälä}
 
@@ -29,8 +29,7 @@
 
 \keywords{Peer-to-Peer, P2P, security, distributed systems, hypermedia systems}
 
-\avainsanat{Vertaisverkot, P2P, tietoturva, hajautetut järjestelmät, 
hypermedia-
-järjestelmät}
+\avainsanat{Vertaisverkot, P2P, tietoturva, hajautetut järjestelmät, 
hypermedia järjestelmät}
 
 \contactinformation{\\
 Hermanni Hyytiälä\\
@@ -177,7 +176,7 @@
 In the loosely structured approach the construction and the maintenance of the 
overlay is controlled 
 loosely. The placement of services and the topology of overlay is random. The 
data lookup model in loosely structured systems is
 not very efficient, because of unstructured properties of the overlay. Data 
lookup model is a combination of methods which 
-are used for locatin data in the overlay.  
+are used for locating data in the overlay.  
 
 \subsection{Definition}
 
@@ -293,7 +292,7 @@
 
 Partly due to scalability problems of loosely structured systems, several 
tightly 
 structured overlays have been proposed. In the tightly structured
-approach the overlay is constructed determistically, which all participating 
peers have to follow; the topology of the
+approach the overlay is constructed deterministically, which all participating 
peers have to follow; the topology of the
 overlay and the placement of services is controlled tightly.
 
 \subsection{Definition}
@@ -311,13 +310,13 @@
 which maps data items, expressed by an identifier to coordinate point $ip$ in 
$(IS,d)$. Peer's $p$ 
 resources are mapped onto a set $IS$ = \{$ip \in IS: \exists s \in S$, $ip = 
\zeta(\iota(s)) \wedge (\delta(s) = p)$\}.
 Every $p$ has neighbor(s), named as $p_n$, $P$ = \{$p \in P: \exists p_n$, 
-where $\theta(p,p_n) = ''close''$, where $''close''$ is small difference $d$ 
in $(IS,d)$\}.
+where $\theta(p,p_n)$ = ''close'', and ''close'' is small difference $d$ in 
$(IS,d)$\}.
 
 \subsection{Systems}
  
 With tightly structured systems, it is feasible to perform \emph{global} data 
lookups in the overlay efficiently. By global lookup, we mean
 that the system is able to find a service from the overlay, if it exists in 
the overlay.
-While there are significant differences among proposed tighty structured 
systems, they all have in common
+While there are significant differences among proposed tightly structured 
systems, they all have in common
 that \emph{peer identifiers} are assigned to participating peers from
 a large \emph{identifier space} by the overlay. Globally unique identifiers 
 are also assigned to application-specific data items, \emph{keys}, 
@@ -820,7 +819,7 @@
 In this chapter, we discuss open problems in Peer-to-Peer research.
 Note that the open problems list considered here is not meant
 to be an exhaustive survey of \emph{all} open problems in Peer-to-Peer domain; 
-we focus our attention to some issues related security, scalability, usability 
and performance. 
+we focus our attention to some issues related to security, scalability, 
usability and performance. 
 
 
 \section{Overview}
@@ -857,7 +856,7 @@
 the Distributed Denial of Service attack. 
 
 In the Sybil attack model \cite{douceur02sybil}, a hostile entity presents 
multiple 
-entities, i.e., when a peer communicates with a subset of other participating 
entities to perform a operation, a peer communicates 
+entities, i.e., when a peer communicates with a subset of other participating 
entities to perform an operation, a peer communicates 
 only with the same hostile entity. Hostile entity can control a large fraction 
of Peer-to-Peer system while
 repressing the redundancy of the system. Authors argue in  
\cite{douceur02sybil} that without a centralized authority, Sybil attacks are 
always possible in a Peer-to-Peer 
 system except under extreme and unrealistic assumptions of resource parity and 
coordination among entities. Unrealistic assumptions include: all entities 
@@ -868,7 +867,7 @@
 They call this method as a one form of \emph{self-certifying data}. 
  
 In the Fail-stop attack model, cited in \cite{naor03simpledht}, a faulty peer 
is deleted from the Peer-to-Peer system. Thus,
-a specific data item can be lost from the system temporaraly (or permanently). 
The reason for the faultiness of a peer can be a 
+a specific data item can be lost from the system temporarily (or permanently). 
The reason for the faultiness of a peer can be a 
 software failure or a hostile attack. The Byzantine attack model \cite{357176} 
is closely related to Fail-stop model. In the Byzantine attack model
 $3f + 1$ is the minimum number of peers that allow system to provide the 
safety and liveness properties when up to $f$ peers are faulty \cite{357176}.  
 The Byzantine model can be seen as more severe than Fail-stop model as there 
are no restrictions over the behavior of faulty peers, e.g., the cooperation 
@@ -876,7 +875,7 @@
 proposed by Castro et al. \cite{296824}. Authors use in their work replication 
algorithm to tolerate Byzantine faults and cryptographic 
 certificate techniques to prevent spoofing and replays to detect corrupted 
messages.
 
-The Spam generating attack \cite{naor03simpledht} is an another known attack 
model against Peer-to-Peer system. In the Spam
+The Spam generating attack \cite{naor03simpledht} is another known attack 
model against Peer-to-Peer system. In the Spam
 attack, a hostile or faulty peer may produce false information of the data, or 
refuses to (or is not able to) reply to requests. 
 Naor et al. \cite{naor03simpledht} have proposed a partial solution against 
Spam attack in a \emph{faulty} peer environment (not hostile).
 
@@ -924,7 +923,7 @@
 According to \cite{dingledine00free}, there exist several kinds of anonymity: 
author-anonymity, 
 publisher-anonymity, reader-anonymity, peer-anonymity and query-ano-nymity. 
Author-anonymity is a form
 of anonymity in which no one can link author (who created the document) to a 
document. 
-Publisher-anonymity means that no one is able to determine the publisher (how 
published the document into
+Publisher-anonymity means that no one is able to determine the publisher (who 
published the document into
 the system) of a document. Reader-anonymity means that a document cannot be 
linked to its readers.
 With peer-anonymity, no one is able to determine the peer, where the document 
was originally published.
 Document-anonymity means that a peer doesn't know which data it is currently 
hosting. Finally, query-anonymity is a form
@@ -932,7 +931,7 @@
 to the data lookup originators. As the authors of \cite{dingledine00free} 
cite, some forms of anonymity 
 may imply each other and possible issues raised by this property is one area 
of future work.
 
-Obviously, existance of several types of anonymity often conflicts with other 
key properties of
+Obviously, existence of several types of anonymity often conflicts with other 
key properties of
 Peer-to-Peer systems. Let us consider anonymity and efficient data lookup. In 
efficient data lookup, we must know
 the peers responsible for given data. Of course, when we know the peers 
responsible
 for the data, the anonymity of peer is lost. Fortunately, there are partial 
solutions to these kinds of
@@ -947,7 +946,7 @@
 distributed systems which are able to provide some level of anonymity (e.g., 
\cite{mneturl}).
 
 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 complete anonymity in all levels (see 
above). Specifically, the conflicts
+such system which is able to provide complete anonymity in all levels (see 
above). Specifically, the conflicts
 between anonymity and other properties of Peer-to-Peer system require more 
research work.
 
 
@@ -971,18 +970,18 @@
 \subsection{Hostile entities}
 
 One serious problem in Peer-to-Peer systems is the inability to distinguish 
hostile entities from regular entities
-trustworthy. Identification of hostile entities is essential in the tightly 
structured 
+trustworthly. Identification of hostile entities is essential in the tightly 
structured 
 approach, in which the fundamental (and implicit) assumption is that there is 
a random, uniform distribution 
 of peer identifiers that cannot be controlled by a hostile entity.
 
 One possible solution is to use a self-monitoring system, such as SOMO 
\cite{zhang03somo}, in which a self-monitoring overlay
 constantly analyses the Peer-to-Peer overlay. Self-monitoring overlay is built 
on top of Peer-to-Peer overlay. Authors in
-\cite{sit02securitycons} suggest the use of system invariants. They emphasize 
that system invariants should be veriable, and if
+\cite{sit02securitycons} suggest the use of system invariants. They emphasize 
that system invariants should be verifiable, and if
 system invariants fail the system must have a recovery mechanism. In 
distributed peer identifier assignment \cite{castro02securerouting, 
clarke00freenet}, 
 multiple participating peers participate in a creation of peer identifier. 
 
 Centralized authorities could be used for the assignment of peer identifiers, 
but they may not be suitable
-for ad hoc Peer-to-Peer environrment and have property of single point of 
failure. Distributed peer 
+for ad hoc Peer-to-Peer environment and have property of single point of 
failure. Distributed peer 
 identification assignment can be problematic as long as the Sybil attack 
\cite{douceur02sybil} remains unsolved. 
 However, there are some partial solutions for controlling the \emph{rate} at 
which hostile entity is able to obtain peer 
 identifier, such as crypto-based puzzles \cite{juels99clientpuzzles}.
@@ -1001,13 +1000,13 @@
 Authors argue in \cite{castro02securitystructured} that with the combination 
of 
 secure peer identifer assignment, secure routing table maintenance and secure 
message forwarding
 secure query routing in tightly structured systems is possible. Additionally, 
authors cite in \cite{castro02securerouting} 
-that the probability of routing successfully between to arbitrary 
+that the probability of routing successfully between arbitrary 
 correct peers is $(1-f)^{h-1}$, when a fraction $f$ of the other peers are 
faulty or hostile and where
 $h$ is the number of hops in the overlay. Sit and Morris 
\cite{sit02securitycons} discuss the possibility of 
 allowing the query originator to observe lookup progress and cross-check 
routing tables using random queries to achieve
 secure routing in tightly structured overlay. However, their
 approach is not very efficient, since this method creates lot of additional 
network traffic when
-in function i.e., it is unknown if this techique is realizable in a efficient 
way.
+in function i.e., it is unknown if this technique is realizable in an 
efficient way.
 Lynch et al. \cite{lynch02atomicdataaccess} propose a solution for secure 
routing table 
 maintenance, but their solution seems to have two major problems according to 
\cite{castro02securitystructured}. 
 First, the solution is very expensive even without faulty or hostile entities. 
Second, each group of replicas
@@ -1025,7 +1024,7 @@
 
 Ross Lee Graham lists several external threats against Peer-to-Peer networks 
\cite{grahamp2psecurity}. Most important, 
 the list includes viruses and trojans. Currently, there are not even partial 
solutions
-to the problems mentioned above.  The reason for this is that there are no 
experience about these kinds of 
+to the problems mentioned above.  The reason for this is that there is no 
experience about these kinds of 
 attacks. Possible solution would be a distributed anti-virus software, but 
much more intensive research is required until
 this kind of solution would be applicable.
 
@@ -1119,7 +1118,7 @@
 \parbox{90pt}{Access Control \cite{nejdl03accesscontrol, 
daswani03openproblems}} &
 \parbox{110pt}{Can we define access control levels in Peer-to-Peer network ?} &
 \parbox{110pt}{Schema-based rules} &
-\parbox{110pt}{Some initial experiences, need more research}
+\parbox{110pt}{Some initial experiences, needs more research}
 \\ \hline
 
 
@@ -1140,7 +1139,7 @@
 \parbox{90pt}{External security threats \cite{grahamp2psecurity}} &
 \parbox{110pt}{Viruses, trojans, sniffers} &
 \parbox{110pt}{Data integrity/authenticity, distributed anti virus software} &
-\parbox{110pt}{Not much research has been done on this}
+\parbox{110pt}{Not much research has been done on this area}
 \\ \hline
 
 \caption{Security problems in Peer-to-Peer.} 
@@ -1168,7 +1167,7 @@
 with successively larger TTL depth limits, until either the query is 
satisfied, 
 or the maximum depth $D$ has been reached. Expanding ring, proposed by Shenker 
et al. in \cite{lv02searchreplication}, 
 is similar to the iterative deepening technique. In this method, a peer starts 
a flood with small TTL, and 
-waits to see if the search is successful. If it is, then the peer stops the 
data lookuo. Otherwise, the peer increases 
+waits to see if the search is successful. If it is, then the peer stops the 
data lookup. Otherwise, the peer increases 
 the TTL and starts another data lookup. With these techniques, searches 
 may not be fast when desired data item requires several consecutive flooding 
rounds.
 
@@ -1177,7 +1176,7 @@
 thereby maintaining the quality of costs and decreasing the amount
 of messages sent to network. 
 
-In the local indices techique \cite{yang02improvingsearch}, each peer 
maintains an index over the data of all peers within 
+In the local indices technique \cite{yang02improvingsearch}, each peer 
maintains an index over the data of all peers within 
 $h$ hops of itself, where $h$ is a system-wide variable, called radius of the
 index\footnote{In the normal BFS case, the value of $h$ is 0, as a peer only 
has index
 over its local content.}. Thus, when a peer receives a data lookup request, it 
can
@@ -1196,7 +1195,7 @@
 Depth-First-Search (DFS) and peers' routing tables are dynamically built
 using caching. This is an outcome of Freenet's main design principles, 
anonymity. 
 Another property of the Freenet's data lookup model is that
-it adapts well with varying usage patterns (e.g., searching for popular data 
items in the overlay). 
+it adapts well to varying usage patterns (e.g., searching for popular data 
items in the overlay). 
 Improvements to Freenet's data lookup using
 the ''small-world'' techniques have been proposed by Zhang et al. 
\cite{zhang02using}.
 
@@ -1237,7 +1236,7 @@
 is designed for the CAN system \cite{ratnasamy01can}.
 
 Recent study has been focused on the feasibility of Peer-to-Peer Web-like 
indexing and searching 
-on top of tightly structured overlays \cite{li03feasibility} . Authors argue, 
that it is possible to implement 
+on top of tightly structured overlays \cite{li03feasibility}. Authors argue, 
that it is possible to implement 
 Peer-to-Peer Web-like search with certain compromises. First, Peer-to-Peer 
search engine may need to 
 decrease the result quality in order to make searching more efficient. Second, 
Peer-to-Peer systems must 
 consult the properties of underlying network for better performance.
@@ -1270,7 +1269,7 @@
 Almost all presented algorithms 
 for the tightly structured systems have been analyzed under static simulation 
 environments \cite{libennowell01observations}. Furthermore, proposed tightly 
structured overlays are configured statically to achieve 
-the desired reliability even in a uncommon and adverse environment 
\cite{rowston03controlloingreliability}. 
+the desired reliability even in an uncommon and adverse environment 
\cite{rowston03controlloingreliability}. 
 Thus, one of the most important factors for future research is to get 
real-life experiences from tightly structured 
 systems, when there are frequent joins and leaves of peers in the system.
 
@@ -1278,7 +1277,7 @@
 distribution of peer and key identifiers. Even if participating peers are 
extremely heterogeneous, e.g., in
 computing power or network bandwidth, all data items are distributed 
uniformly. Clearly, this is
 a serious problem of tightly structured overlays in face of performance and 
load balancing \cite{rao03loadbalancing}. 
-Measurement study by Saroiu et al. show that there is a extreme heterogeneity 
among participating peers in already deployed Peer-to-Peer 
+Measurement study by Saroiu et al. show that there is extreme heterogeneity 
among participating peers in already deployed Peer-to-Peer 
 systems \cite{saroiu02measurementstudyp2p}. 
 
 Some research has been done with regard to load balancing properties of 
tightly structured
@@ -1299,12 +1298,11 @@
 Hot spots happen, when a specific key is being requested extremely often in 
tightly structured overlays. Recent study 
 by Freedman et al. tries to reduce hot spots in the system by performing 
\emph{sloppy} hashing 
 \cite{sloppy:iptps03}. Authors' technique is especially suitable for the DOLR 
abstraction of tightly structured overlays. 
-They arque that with Sloppy hashing, the generation of query hot spots can be 
reduced and peers are able 
-locate nearby data without looking up data from distant peers. Moreover, 
authors' 
-proposal for self-organizing clusters using network diameters. 
+They argue that with Sloppy hashing, the generation of query hot spots can be 
reduced and peers are able 
+locate nearby data without looking up data from distant peers. 
 
 The concept of ''half-life'' was introduced by Liben-Nowell 
\cite{libennowell01observations} since Peer-to-Peer 
-system is \emph{never} in the ''ideal'' state as Peer-to-Peer system is 
continiously evolving system. Half-life is defined
+system is \emph{never} in the ''ideal'' state as Peer-to-Peer system is 
continuously 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 
@@ -1315,7 +1313,7 @@
 Finally, little research has been done regarding self-monitoring. Zhang et al.
 describe an arbitrary data structure on top of a tightly structured overlay 
\cite{zhang03somo}. Authors
 call their technique as a \emph{data overlay}, since it supports several 
fundamental data structures.
-Authors have used this data overlay when building a Self-Organized Meta data 
Overlay (SOMO), which can be used
+Authors have used this data overlay when building a Self-Organized Metadata 
Overlay (SOMO), which can be used
 for monitoring the health of a tightly structured overlay. The fault tolerance 
of SOMO itself is currently
 unknown.
 
@@ -1360,7 +1358,7 @@
 ramanathan02goodpeers, kleinberg99small, nips02-Kleinberg, zhang02using, 
watts00dynamics, karger02findingnearest, 
 brinkmann02compactplacement, rhea02probabilistic, castro02networkproximity, 
ng02predicting, pias03lighthouse, waterhouse02searchp2p, botros01jxtasearch, 
 ganesan02yappers}} &
-\parbox{110pt}{Find resources efficiently, if resource exists (loosely 
structured)} &
+\parbox{110pt}{Find resource efficiently, if resource exists (loosely 
structured)} &
 \parbox{110pt}{Super peers, peer clusters, caching techniques} &
 \parbox{110pt}{More efficient, less network traffic, not comparable to the 
efficiency of tightly structured systems}
 \\ \hline
@@ -1463,13 +1461,13 @@
 All existing Peer-to-Peer systems have rather different interfaces even though 
they have common properties and 
 components (e.g., \cite{zhao03api}). More important, all existing Peer-to-Peer 
systems are incompatible with each other. One
 of the most important area of future research is to create common programming 
abstractions, i.e.,
-interfaces, design patters and frameworks. Also, benchmarks are needed for 
comparing
+interfaces, design patterns and frameworks. Also, benchmarks are needed for 
comparing
 the efficiency of different algorithms equally. 
 
 Recently, there have been few proposals towards common programming guidelines. 
Authors in 
-\cite{zhao03api} propose a higher level abstracions for tightly structured 
overlays. Frise et al. suggest the use of
+\cite{zhao03api} propose a higher level abstractions for tightly structured 
overlays. Frise et al. suggest the use of
 additional layer in Peer-to-Peer system to hide the structure of the overlay 
\cite{frise02p2pframework}. 
-With their abstraction, both the tightly structured and tightly structured 
approach can be used in the system.
+With their abstraction, both the loosely structured and tightly structured 
approach can be used in the system.
 Montresor proposes a framework supporting developers and researchers in the 
design of Peer-to-Peer system
 \cite{babaoglu02anthill}.
 
@@ -1553,7 +1551,7 @@
 
 \parbox{90pt}{Heterogeneity \cite{saroiu02measurementstudyp2p, 
brinkmann02compactplacement, zhao02brocade, gurmeet03symphony, 
rowston03controlloingreliability}} &
 \parbox{110pt}{There are different kind of peers in the system, in light of 
bandwidth and computing power} &
-\parbox{110pt}{Super peers (loosely structured), clusters (loosely structured) 
additional layer upon tighty structured systems, structure itself is simple 
(tighty structured)} &
+\parbox{110pt}{Super peers (loosely structured), clusters (loosely structured) 
additional layer upon tighty structured systems, structure itself is simple 
(tightly structured)} &
 \parbox{110pt}{Working solutions, increases system complexity (additional 
layer)}
 \\ \hline
 
@@ -1581,8 +1579,7 @@
 \parbox{90pt}{Locating Peer-to-Peer network} &
 \parbox{110pt}{How old peers or new peers are able to locate Peer-to-Peer 
network, if it exists} &
 \parbox{110pt}{Servers maintaining online peers (e.g. gnutellahosts.com), 
peer's history information} &
-\parbox{110pt}{Depends on implementation and purpose of the system, for a 
desktop system there are working solutions, for mobile ad hoc networks more 
research is needed (Mobile ad hoc 
-networks (MANETs) can be only connected through radio resource interface, 
i.e., peers which are in same geographical area)}
+\parbox{110pt}{Depends on implementation and purpose of the system, for a 
desktop system there are working solutions}
 \\ \hline
 
 \caption{Miscellaneous problems in Peer-to-Peer.} 
@@ -1603,7 +1600,7 @@
 The Fenfire project \cite{fenfireurl} is an effort to build a location 
transparent, hyperstructured desktop 
 environment. By location transparent, we mean hiding the heterogeneous and 
distributed nature of the system
 so that it appears to the end user like one system and by hyperstructured 
system
-a system in which data can be associated with other data arbitrarly. Fenfire 
uses xanalogical storage model 
+a system in which data can be associated with other data arbitrarily. Fenfire 
uses xanalogical storage model 
 \cite{ted-xu-model} as a basis for hyperstructured media. Each data item in 
the Fenfire system has a globally unique 
 identifier. This property should allow making references between \emph{any} 
 data easier and more seamlessly interoperating than in other systems. For 
location transparency in the Fenfire system, 
@@ -1636,7 +1633,7 @@
 characters\footnote{Xanalogical storage model
 is not limited to text. It can support arbitrary data, e.g., pixels of picture 
or 
 frames of video.}. \emph{Enfilade} is a mutable ''virtual file'' (or part of 
one), which is a list 
-of fluid media content. Fluid media is the smallest units of data in the 
xanalogical storage
+of fluid media content. Fluid media is the smallest unit of data in the 
xanalogical storage
 model (e.g., a character). \emph{Transclusion} is an inclusion in 
 enfilade of contents already used in another enfilade. With the transclusion, 
a system 
 implementing the xanalogical storage model is able to show \emph{all} data 
content that share the same 
@@ -1652,7 +1649,7 @@
 example, presented first time in \cite{lukka02freenetguids}: ''the character 
'D' 
 typed by Janne Kujala on 10/8/97 8:37:18''. When character 
 'D' is first typed in, the xanalogical storage model
-creates a permanent globally identifier for that character 
+creates a permanent identifier for that character 
 and retains it when the character is copied to different document. In 
practice, the xanalogical 
 storage model uses \emph{spans}, ranges of consecutive
 fluid media units to perform storage operations. 
@@ -1679,7 +1676,7 @@
 considered as a collision free hash function. Therefore, it is very unlikely 
that two different Storm data blocks 
 would have same identifier.} \cite{fips-sha-1} is used
 for creating unstructured and semantic-free, globally unique identifiers for 
blocks. Because of SHA-1
-content hash, all identifiers are directly the data verifiers as well. The 
uniquess of blocks creates 
+content hash, all identifiers are directly the data verifiers as well. The 
uniqueness of blocks creates 
 a basis for implementing the xanalogical storage model in the Fenfire system. 
Storm blocks have in common with regular files as they
 both contain the data. The main difference is that Storm blocks are 
\emph{immutable} since any 
 change to the byte sequence would change block's hash value (i.e., globally 
unique identifier).  
@@ -1781,7 +1778,7 @@
 respond to fetching of Storm blocks as fetching can be performed easily once
 Storm block is located. 
 
-In chapter 2, we discussed main the differences between the loosely and the 
tightly structured 
+In chapter 2, we discussed the main differences between the loosely and the 
tightly structured 
 approach. As stated, the most significant difference is that the tightly 
structured 
 approach has at least poly-logarithmical properties in all internal 
operations, while the loosely 
 structured approach doesn't always have even linear properties. Furthermore, 
the
@@ -1925,7 +1922,7 @@
 security is that if a user downloads data from the network to local computer 
 and after a network disconnection, user wants to verify \emph{off line} the 
 authenticity of data. Finally, if a data lookup is performed by a user, but 
there is no reply
-from the Fenfire system, how are we able to know if this was the Spam attack 
\cite{naor03simpledht}, 
+from the Fenfire system, how are we able to know if this was a Spam attack 
\cite{naor03simpledht}, 
 or the data really doesn't exist in the system ?  
 These problems, however, are not only limited to the Fenfire system as it 
 concerns all Peer-to-Peer computer systems.   
Index: gzz/Documentation/misc/hemppah-progradu/storm_pointerblock_creation.eps
diff -u 
gzz/Documentation/misc/hemppah-progradu/storm_pointerblock_creation.eps:1.4 
gzz/Documentation/misc/hemppah-progradu/storm_pointerblock_creation.eps:1.5
--- gzz/Documentation/misc/hemppah-progradu/storm_pointerblock_creation.eps:1.4 
Mon Mar 24 11:08:33 2003
+++ gzz/Documentation/misc/hemppah-progradu/storm_pointerblock_creation.eps     
Thu Mar 27 05:13:05 2003
@@ -1,7 +1,7 @@
 %!PS-Adobe-2.0 EPSF-2.0
 %%Title: storm_pointerblock_creation
 %%Creator: Dia v0.90
-%%CreationDate: Mon Mar 24 18:07:38 2003
+%%CreationDate: Thu Mar 27 12:11:06 2003
 %%For: a user
 %%Magnification: 1.0000
 %%Orientation: Portrait
@@ -92,7 +92,7 @@
  [ /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi
  /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi
  /I /n /v /i /d /u /a /l /xi /xi /space /X /C /r /e /t
- /c /o /s /p /colon /quotesingle /M /y /f /w /g /m /Y /Z /parenleft /parenright
+ /c /o /p /colon /quotesingle /M /y /f /w /s /g /m /Y /Z /parenleft /parenright
  /b /k /D /h /P /S /one /two /three /period /zero /F /xi /xi /xi /xi
  /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi
  /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi
@@ -125,16 +125,16 @@
 n 14.842289 11.769544 11.694378 11.694378 44.732355 119.972279 ellipse s
 0 slj
 n 22.871124 20.849840 m 23.150000 20.000000 l 22.302802 20.286803 l f
-4.839450 2.586290 m /Helvetica_e0 ff 0.700000 scf sf
+4.839450 2.536290 m /Helvetica_e0 ff 0.700000 scf sf
 (*)
  gs 1 -1 sc sh gr
-4.839450 3.286290 m (,-.&/.*&*01!2.3/4)
+4.839450 3.236290 m (,-.&/.*&*01!0.2/3)
  gs 1 -1 sc sh gr
-4.839450 3.986290 m (567*8&"1%-#/.*)
+4.839450 3.936290 m (456*7&"1%-#/.*)
  gs 1 -1 sc sh gr
-4.839450 4.686290 m (!.923&3.-52)
+4.839450 4.636290 m (!.892&2.-49)
  gs 1 -1 sc sh gr
-4.839450 5.386290 m (8-1!/3&:.5)
+4.839450 5.336290 m (7-1!/2&:.4)
  gs 1 -1 sc sh gr
 0.100000 slw
 [0.200000] 0 sd
@@ -144,9 +144,9 @@
 0 slj
 n 21.319436 2.606867 m 22.200000 2.450000 l 21.546168 1.839669 l f
 20.258200 3.436290 m /Helvetica_e0 ff 0.700000 scf sf
-(,-.&/.*&*-&!$1;*2/-#!:4)
+(,-.&/.*&*-&!$1;*9/-#!:3)
  gs 1 -1 sc sh gr
-20.258200 4.136290 m (<+=*>-&!$1;*2/-#!:?)
+20.258200 4.136290 m (<+=*>-&!$1;*9/-#!:?)
  gs 1 -1 sc sh gr
 0.100000 slw
 [] 0 sd
@@ -163,9 +163,9 @@
 2 div 2.505600 ex sub 20.062903 m ( !"#$%&'*<)
  gs 1 -1 sc sh gr
 2.292150 13.886300 m /Helvetica_e0 ff 0.700000 scf sf
-(,-.&/.**&*20-1''*@'10A*=<+*>@'10A* B?)
+(,-.&/.**&*90-1''*@'10A*=<+*>@'10A* B?)
  gs 1 -1 sc sh gr
-2.292150 14.586300 m (&2210#&/.$*9#/C*<+=*>-&!$1;*2/-#!:?)
+2.292150 14.586300 m (&9910#&/.$*8#/C*<+=*>-&!$1;*9/-#!:?)
  gs 1 -1 sc sh gr
 0.100000 slw
 [] 0 sd
@@ -173,34 +173,34 @@
 0 slj
 n 22.100000 10.250000 m 22.100000 12.850000 l 24.950000 12.850000 l 24.950000 
10.250000 l cp s
 25.566300 11.086300 m /Helvetica_e0 ff 0.700000 scf sf
-(D1#!/.-*@'10A4*31#!/.-52)
+(D1#!/.-*@'10A3*21#!/.-49)
  gs 1 -1 sc sh gr
-25.566300 11.786300 m (<+=*/&-:./*#2*@'10A52*)
+25.566300 11.786300 m (<+=*/&-:./*#9*@'10A49*)
  gs 1 -1 sc sh gr
-25.566300 12.486300 m (=<+*;12/*-.0.!/*".-2#1!)
+25.566300 12.486300 m (=<+*;19/*-.0.!/*".-9#1!)
  gs 1 -1 sc sh gr
 11.966200 22.036300 m /Helvetica_e0 ff 0.700000 scf sf
-(>E/1-;*&%/1;&/#0&''7)
+(>E/1-;*&%/1;&/#0&''6)
  gs 1 -1 sc sh gr
-11.966200 22.736300 m (0-.&/.2*&*31#!/.-*@'10A?)
+11.966200 22.736300 m (0-.&/.9*&*21#!/.-*@'10A?)
  gs 1 -1 sc sh gr
 12.337000 2.436290 m /Helvetica_e0 ff 0.700000 scf sf
-(>E/1-;*&%/1;&/#0&''7)
+(>E/1-;*&%/1;&/#0&''6)
  gs 1 -1 sc sh gr
-12.337000 3.136290 m (0-.&/.2*&*-&!$1;*2/-#!:?)
+12.337000 3.136290 m (0-.&/.9*&*-&!$1;*9/-#!:?)
  gs 1 -1 sc sh gr
 0.976471 0.156863 0.184314 srgb
 /Helvetica_e0 ff 0.800000 scf sf
-(E/.3*F) sw
-2 div 7.056350 ex sub 6.536290 m (E/.3*F)
+(E/.2*F) sw
+2 div 7.056350 ex sub 6.536290 m (E/.2*F)
  gs 1 -1 sc sh gr
 /Helvetica_e0 ff 0.800000 scf sf
-(E/.3*G) sw
-2 div 6.241600 ex sub 12.762900 m (E/.3*G)
+(E/.2*G) sw
+2 div 6.241600 ex sub 12.762900 m (E/.2*G)
  gs 1 -1 sc sh gr
 /Helvetica_e0 ff 0.800000 scf sf
-(E/.3*H) sw
-2 div 29.041600 ex sub 10.212900 m (E/.3*H)
+(E/.2*H) sw
+2 div 29.041600 ex sub 10.212900 m (E/.2*H)
  gs 1 -1 sc sh gr
 0.100000 slw
 [] 0 sd
@@ -259,9 +259,9 @@
 0 slj
 n 22.100000 17.100000 m 22.100000 19.550000 l 24.900000 19.550000 l 24.900000 
17.100000 l cp s
 22.350000 17.736300 m /Helvetica_e0 ff 0.700000 scf sf
-(K#-2/*)
+(K#-9/*)
  gs 1 -1 sc sh gr
-22.350000 18.436300 m (".-2#1!4)
+22.350000 18.436300 m (".-9#1!3)
  gs 1 -1 sc sh gr
 22.350000 19.136300 m (FIFIGJJH)
  gs 1 -1 sc sh gr
@@ -296,9 +296,9 @@
 0 slc
 n 6.900000 19.200000 m 6.900000 20.000000 l s
 5.650000 20.586300 m /Helvetica_e0 ff 0.700000 scf sf
-(K#-2/*)
+(K#-9/*)
  gs 1 -1 sc sh gr
-5.650000 21.286300 m (".-2#1!4)
+5.650000 21.286300 m (".-9#1!3)
  gs 1 -1 sc sh gr
 5.650000 21.986300 m (FIFIGJJH)
  gs 1 -1 sc sh gr