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: Wed, 12 Mar 2003 08:41:17 -0500

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Hermanni Hyytiälä <address@hidden>      03/03/12 08:41:17

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

Log message:
        More fixes

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

Patches:
Index: gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
diff -u gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.131 
gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.132
--- gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.131      Wed Mar 
12 07:57:42 2003
+++ gzz/Documentation/misc/hemppah-progradu/masterthesis.tex    Wed Mar 12 
08:41:17 2003
@@ -1363,7 +1363,7 @@
 
 
 \parbox{90pt}{Sybil attack \cite{douceur02sybil}, 
\cite{castro02securerouting}} &
-\parbox{110pt}{Single hostile entity present multiple entities} &
+\parbox{110pt}{Single hostile entity presents multiple entities} &
 \parbox{110pt}{Identify all nodes simultaneously across the system, collect 
pool of nodes which are validated, distributed node ID creation} &
 \parbox{110pt}{Not practically realizable, research focused on persistence, 
not on identity distinction}
 \\ \hline 
@@ -1397,7 +1397,7 @@
 \\ \hline
 
 
-\parbox{90pt}{Anonymity \cite{reiter98crowds}, \cite{tarzan:ccs9}, 
\cite{pub00}, \cite{clarke00freenet}, \cite{reiter98crowds}, 
\cite{352607},\cite{502002}} &
+\parbox{90pt}{Anonymity \cite{tarzan:ccs9}, \cite{pub00}, 
\cite{clarke00freenet}, \cite{reiter98crowds}, \cite{352607},\cite{502002}} &
 \parbox{110pt}{Anonymity cannot be provided in all cases} &
 \parbox{110pt}{Remailers, pre-routing} &
 \parbox{110pt}{Total anonymity cannot be provided yet}
@@ -1427,13 +1427,13 @@
 
 \parbox{90pt}{Hostile groups \cite{castro02securerouting}} &
 \parbox{110pt}{Joining node may join parallel network, formed a group of 
hostile nodes, hostile node(s) controls the construction of the network} &
-\parbox{110pt}{Use trusted nodes, based on history information, Cryptography, 
key infrastructure} &
+\parbox{110pt}{Use trusted nodes, based on history information, cryptography, 
key infrastructure} &
 \parbox{110pt}{Not 100\% sure if Central Authority (CA) is missing, not 
practical approach/working proposal created yet}
 \\ \hline
 
 
 \parbox{90pt}{External security threats} &
-\parbox{110pt}{Viruses, Trojan, sniffers} &
+\parbox{110pt}{Viruses, trojans, sniffers} &
 \parbox{110pt}{Data integrity/authenticity, distributed anti virus software} &
 \parbox{110pt}{Not much research has been done on this}
 \\ \hline
@@ -1476,7 +1476,7 @@
 \\ \hline
 
 
-\parbox{90pt}{Efficient and scalable data discovery 
\cite{lv02searchreplication}, \cite{osokine02distnetworks}, 
\cite{yang02improvingsearch}, \cite{lv02gnutellascalable}, 
\cite{ganesan02yappers}, \cite{adamic02localsearch}, 
\cite{adamic01powerlawsearch}, \cite{ripeanu02mappinggnutella}, 
\cite{milgram67smallworld}, \cite{adamic99small}, \cite{sterling95beowulf}, 
\cite{ramanathan02goodpeers}, \cite{kleinberg99small}, \cite{nips02-Kleinberg}, 
\cite{zhang02using}, \cite{watts00dynamics}} &
+\parbox{90pt}{Efficient and scalable data discovery 
\cite{lv02searchreplication}, \cite{osokine02distnetworks}, 
\cite{yang02improvingsearch}, \cite{lv02gnutellascalable}, 
\cite{ganesan02yappers}, \cite{adamic02localsearch}, 
\cite{adamic01powerlawsearch}, \cite{ripeanu02mappinggnutella}, 
\cite{milgram67smallworld}, \cite{adamic99small}, \cite{ramanathan02goodpeers}, 
\cite{kleinberg99small}, \cite{nips02-Kleinberg}, \cite{zhang02using}, 
\cite{watts00dynamics}} &
 \parbox{110pt}{Find resources efficiently, if resource exists (loosely 
structured)} &
 \parbox{110pt}{Super nodes, node clusters, caching techniques} &
 \parbox{110pt}{More efficient, less network traffic, not comparable to DHT's 
efficiency}
@@ -1498,7 +1498,7 @@
 
 
 \parbox{90pt}{Quality of Service} &
-\parbox{110pt}{The system can only provide (at most) best effort services)} &
+\parbox{110pt}{The system can only provide (at most) best effort services} &
 \parbox{110pt}{Use network proximity for better network performance 
(bandwidth, latency, jitter, packet loss)} &
 \parbox{110pt}{Increases system complexity, some initial experiences, need 
more research}
 \\ \hline
@@ -1512,8 +1512,8 @@
 
 
 \parbox{90pt}{Network proximity \cite{pias03lighthouse}, 
\cite{ng02predicting}, \cite{ratnasamy02ght}, \cite{eriksson03peernet}, 
\cite{castro02networkproximity}} &
-\parbox{110pt}{Can we take account the underlying network's properties better 
when forming overlay network (network-awareness for performance) ?} &
-\parbox{110pt}{Global Network Positioning, Lighthouse technique, triangulated 
heuristics} &
+\parbox{110pt}{Can we take into account the underlying network's properties 
better when forming overlay network (network-awareness for performance) ?} &
+\parbox{110pt}{Global network positioning, lighthouse technique, triangulated 
heuristics} &
 \parbox{110pt}{Increases system complexity, no real world experience in a wide 
scale, proposed solutions are susceptible to single point of failure}
 \\ \hline
 
@@ -1528,12 +1528,12 @@
 \parbox{90pt}{Hot spots \cite{258660}, \cite{sloppy:iptps03}, 
\cite{maymounkov03ratelesscodes}} &
 \parbox{110pt}{What will happen if some resource is extremely popular and only 
one node is hosting it ?} &
 \parbox{110pt}{Caching, multi source downloads, replication, load balancing, 
sloppy hashing} &
-\parbox{110pt}{For query hot spots, caching and multi source downloads 
efficiently reduces hot spots, for routing hot spots, benefits are smaller}
+\parbox{110pt}{For query hot spots, caching and multi source downloads 
efficiently reduce hot spots, for routing hot spots, benefits are smaller}
 \\ \hline
 
 
 \parbox{90pt}{Load balancing \cite{rao03loadbalancing}, 
\cite{ledlie02selfp2p}, \cite{byers03dhtbalancing}} &
-\parbox{110pt}{Random (but uniformly distributed) identifier selection could 
cause system imbalance among participants with different capabilities} &
+\parbox{110pt}{Random (but uniformly distributed) identifier selection could 
cause system inbalance among participants with different capabilities} &
 \parbox{110pt}{Caching, virtual server transfers} &
 \parbox{110pt}{Effective, more research required in fully dynamic environment}
 \\ \hline
@@ -1546,21 +1546,21 @@
 
 \parbox{90pt}{Sudden network partition \cite{harvey03skipnet1}, 
\cite{harvey03skipnet2}, \cite{rowston03controlloingreliability}} &
 \parbox{110pt}{Sub network is isolated from other network because of network 
disconnection} &
-\parbox{110pt}{Self-tuning, environment observatorion, localized network 
connection for minimum latency (backup connections)} &
+\parbox{110pt}{Self-tuning, environment observation, localized network 
connection for minimum latency (backup connections)} &
 \parbox{110pt}{Creates more overhead/space requirements per node}
 \\ \hline
 
 \parbox{90pt}{Fail Stop} &
 \parbox{110pt}{A faulty node stops working} &
 \parbox{110pt}{Failure detectors, informing algorithms} &
-\parbox{110pt}{Creates more network traffics, node's information can be 
outdated, failure detectors not reliable}
+\parbox{110pt}{Creates more network traffic, peer's information can be 
outdated, failure detectors not reliable}
 \\ \hline
 
 
 \parbox{90pt}{Byzantine faults \cite{296824}} &
 \parbox{110pt}{Faulty nodes may behave arbitrarily} &
-\parbox{110pt}{Byzantine replication algorithms -> get information from 
multiple entities, trust majority's opinion} &
-\parbox{110pt}{Much research has been done on this field, practical solutions, 
decreases the performance of system slightly}
+\parbox{110pt}{Byzantine replication algorithms, get information from multiple 
entities, trust majority's opinion} &
+\parbox{110pt}{Much research has been done on this field, practical solutions, 
decreases system performance slightly}
 \\ \hline
 
 \caption{Performance and usability problems in Peer-to-Peer.} 
@@ -1595,7 +1595,7 @@
 \endfoot
 
 
-\parbox{90pt}{Mutual distrust, \cite{cornelli02reputableservents}, 
\cite{aberer01trust}} &
+\parbox{90pt}{Mutual distrust \cite{cornelli02reputableservents}, 
\cite{aberer01trust}} &
 \parbox{110pt}{Nobody trusts anybody} &
 \parbox{110pt}{Reputation methods, key infrastructures} &
 \parbox{110pt}{Resource demanding, not practical to implement/not working 
solutions, no real world experience in a wide scale}
@@ -1624,7 +1624,7 @@
 
 
 \parbox{90pt}{Comprehensive simulations/analysis of Peer-to-Peer network} &
-\parbox{110pt}{Ability to simulate whole Peer-to-Peer network's usage 
patterns, network traffics, flux state etc} &
+\parbox{110pt}{Ability to simulate whole Peer-to-Peer network's usage 
patterns, network traffics, flux state etc.} &
 \parbox{110pt}{Use same techniques as simulating/analyzing the Internet} &
 \parbox{110pt}{Only small subsets of Peer-to-Peer networks has been analysed, 
because of ad hoc properties of network, more powerful solutions needed}
 \\ \hline
@@ -1633,13 +1633,14 @@
 \parbox{90pt}{Overlay management and health monitoring \cite{zhang03somo}} &
 \parbox{110pt}{System is self-capable to monitor it's status and health for 
better performance} &
 \parbox{110pt}{Build a meta data overlay atop of structured overlay (such as 
SOMO for structured overlays), make local decisions about overlay 
(unstructured)} &
-\parbox{110pt}{For structured overlays, efficient and simple to implement, 
fault-tolerance unknowns, for unstructured, not necessarily efficient because 
decisions are based on local knowledge}
+\parbox{110pt}{For tightly structured overlays, efficient and simple to 
implement, fault tolerance unknown, for loosely structured not necessarily 
efficient because decisions are based on local knowledge}
 \\ \hline
 
 \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 mobile 
ad hoc networks more research is needed}
+\parbox{110pt}{Depends on implementation and purpose of the system, for 
desktop based system there are working solutions, for mobile ad hoc networks 
more research is needed (Mobile ad hoc 
+networks (MANETs) can be only connected through radio resource interface, 
i.e., peers which are in same geographical area)}
 \\ \hline
 
 \caption{Miscellaneous problems in Peer-to-Peer.} 
@@ -1688,7 +1689,7 @@
 \emph{characters}. Each character in xanalogical storage model has a
 permanent, globally unique identifier. For instance, let's consider the 
following
 scenario: ''the character 'D' typed by Janne Kujala on 10/8/97 8:37:18''. In 
this
-example, when character 'D' is is first typed in, xanalogical storage model
+example, when character 'D' is first typed in, xanalogical storage model
 acquires a permanent identifier for that character and retains it when 
character
 is copied to different document. Thus, the identifier distinguishes character 
from 
 all similar characters typed in independently\footnote{Xanalogical storage 
model
@@ -1728,13 +1729,13 @@
 
 Storm (for \emph{STORage Module}) is a software module, which is used in 
Fenfire for
 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 
+are immutable byte sequences. SHA-1\footnote{SHA-1 is considered as 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 location-independent, globally unique identifiers for blocks. 
Additionally,
 SHA-1 \cite{fips-sha-1} is used for verifying the integrity of Storm data 
blocks. Storm
-blocks have much in common with regular files, except Storm blocks are 
\emph{immutable} as
-any change to the byte sequence would the change block's hash value, i.e., 
unique 
+blocks have much in common with regular files, except that Storm blocks are 
\emph{immutable} as
+any change to the byte sequence would change block's hash value, i.e., unique 
 identifier. This mechanism creates a basis for implementing xanalogical model 
in 
 Fenfire system. Figure \ref{fig:storm_model} illustrates simplified Storm 
storage model.
 
@@ -1805,23 +1806,23 @@
 Obviously, our objectives are yet simple but hard to fulfill. First, as a 
prerequisite
 to implementing xanalogical storage model in Peer-to-Peer environment, system
 supporting data lookups must be able to perform \emph{global} scale lookups. 
Thus, 
-we must able to locate and fetch Storm scroll/pointer block, if it exists in 
the 
+we must be able to locate and fetch Storm scroll/pointer block, if it exists 
in the 
 Peer-to-Peer overlay. Second, data lookups have to be efficient, since 
constructing 
 one ''virtual file'' may need obtaining several data items, which are 
distributed 
 randomly throughout the overlay; if not efficient, construction of ''virtual 
file''
-may take reasonable amount time while rendering system very unusable. Third, 
Peer-to-Peer 
+may take reasonable amount of time while rendering system very unusable. 
Third, Peer-to-Peer 
 infrastructure has to be scalable and robust against hostile attacks.
 
 Some research regarding to these problem has been made by Lukka et al. 
 \cite{lukka02freenetguids}. Authors' work is mainly based on insight of 
implementing
 xanalogical model in Peer-to-Peer environment with globally unique 
identifiers. Lukka et al.
-use Freenet \cite{clarke00freenet} as a example Peer-to-Peer system supporting 
+use Freenet \cite{clarke00freenet} as an example Peer-to-Peer system 
supporting 
 globally unique identifiers. The work presented in this thesis extends their 
work by 
 evaluating different Peer-to-Peer systems more extensively to Fenfire's needs.
  
 Additionally, related to non-xanalogical hypermedia systems, Bouving 
 \cite{bouvin02openhypermedia} has done initial work regarding  ways in which 
-Peer-to-Peer can used in non-xanalogical hypermedia systems. Thompson and de 
Roure 
+Peer-to-Peer can be used in non-xanalogical hypermedia systems. Thompson and 
de Roure 
 \cite{thompson01hypermedia} have studied locating documents and links in 
Peer-to-Peer
 environment. At the Hypertext '02 panel, moderated by Wiil 
\cite{wiil02p2phypertext},
 participants responded whether Peer-to-Peer systems are suitable for hypermedia
@@ -1832,7 +1833,7 @@
 In chapter 2, we discussed main differences between loosely and tightly 
structured 
 approaches. As stated, the most significant difference is that tightly 
structured 
 approach has logarithmical properties in all internal operations, while 
loosely 
-structured approach doesn't have always even linear properties. Furthermore, 
the
+structured approach doesn't always have even linear properties. Furthermore, 
the
 data lookup model of tightly structured overlay scales much better than 
loosely 
 structured overlays; tightly structured overlay supports global data lookups
 in the overlay, whereas the data lookup model of loosely structured approach
@@ -1852,7 +1853,7 @@
 \emph{semantic free}. Finally, as said, with tightly structured systems, it is 
feasible to 
 perform \emph{global} data lookups in the overlay. To summarize, these aspects 
may be the most important features 
 of Peer-to-Peer infrastructure with regard to Fenfire as a \emph{distributed} 
hypermedia system.
-Thus, we see the tightly structured approach the best alternative to locate 
data in Peer-to-Peer
+Thus, we see the tightly structured approach as the best alternative to locate 
data in Peer-to-Peer
 environment.
 
 Once located, for \emph{fetching} Fenfire related data from the overlay, we 
can use regular 
@@ -1873,7 +1874,7 @@
 
 Again, there are open issues with tightly structured systems which have to be
 addressed, as described in chapter 3. The main concerns include decreased 
performance and fault 
-tolerance when system in flux-state, non-optimal distance functions in 
identifier space, 
+tolerance when system in presence of system flux, non-optimal distance 
functions in identifier space, 
 proximity routing, hostile entities and flexible search 
\cite{balakrishanarticle03lookupp2p}.
 Additionally, there is only little real world experiments yet with tightly 
structured systems
 (e.g., \cite{overneturl}, \cite{edonkey2kurl}). Therefore, we can't say for 
sure, how well these 
@@ -1884,8 +1885,8 @@
       
 \section{Fenfire system model in Peer-to-Peer environment}
 
-In this section present a proposal of Fenfire Peer-to-Peer system, which 
consists 
-of several technologies presented in this thesis.  Then, we introduce yet 
simple but 
+In this section we give a proposal of Fenfire Peer-to-Peer system, which 
consists 
+of several technologies reviewed in this thesis.  Then, we introduce yet 
simple but 
 effective algorithms for obtaining Fenfire data from Peer-to-Peer environment. 
  
 \subsection{System proposal}
@@ -1898,8 +1899,8 @@
 \cite{kato02gisp}), which means that Kademlia's algorithm is simple and easy 
to implement.
 
 On top of Kademlia, we propose the usage of Sloppy hashing 
\cite{sloppy:iptps03} which
-optimized for DOLR abstraction of tightly structured overlays. With Sloppy 
hashing, 
-we are able reduce of generation of query hot spots. Sloppy hashing enables to 
+is optimized for DOLR abstraction of tightly structured overlays. With Sloppy 
hashing, 
+we are able to reduce the generation of query hot spots. Sloppy hashing 
enables to 
 locate nearby data without looking up data from distant nodes. Moreover, 
authors' 
 proposal for self-organizing clusters using network diameters may be useful, 
 especially within small groups of working people. Thus, with Sloppy hashing
@@ -1913,16 +1914,16 @@
 Finally, for more efficient data transfer, we can use variable techniques for 
this purpose.
 For small amounts of data, HTTP can be used \cite{rfc2068}. For big downloads, 
we can use
 multi source downloads for better efficiency and reliability. Specifically, 
technology based
-on rate less erasure codes \cite{maymounkov03ratelesscodes} seems very 
promising.
+on rateless erasure codes \cite{maymounkov03ratelesscodes} seems very 
promising.
 
 \subsection{Algorithms}
 
-We use DOLR abstraction of tightly of structured approach, i.e., each 
participating peer hosts 
+We use DOLR abstraction of tightly structured approach, i.e., each 
participating peer hosts 
 the data and overlay maintains only the \emph{pointers} to the data. We 
decided to use DOLR in our
 model, since DOLR systems locate data without specifying a storage policy 
explicitly \cite{rhea03benchmarks}. 
 DHT based storage systems, such as CFS \cite{dabek01widearea} and PAST 
\cite{rowstron01storage}, may have
 critical problems with load balancing in highly heterogeneous environment. 
This problem is caused by peers 
-which may not able to store relative great amount of data with key/value pair, 
assigned randomly by 
+which may not be able to store relatively large 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).
 
@@ -1960,7 +1961,7 @@
 \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 pointer random string.
+\item Query originator locally computes a hash for given pointer random string.
 \item Repeat until hosting peer is found: each peer forwards the data lookup 
to a closer peer which hosts the given hash of pointer random string.
 \item Pointer peer returns most recent pointer block's key/value-pair (e.g., 
hosting peer's IP-address) to query originator, using pointer block's own 
indexing schemes. 
 \item Query originator requests hosting peer to return the scroll block.
@@ -1971,7 +1972,7 @@
 \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 pointer random string.
+\item Query originator locally computes a hash for given pointer random string.
 \item Repeat until hosting peer is found: each peer forwards the data lookup 
to a closer peer which hosts the given hash of pointer random string.
 \item Pointer peer returns pointer block's key/value-pair(s) (e.g., hosting 
peer's IP-addresses) to query originator, using pointer block's own indexing 
schemes. 
 \item Query originator requests hosting peer to return the scroll block.
@@ -2008,11 +2009,11 @@
 security technologies. For instance, online entities cannot be identified 
 safely (e.g., the Sybil attack \cite{douceur02sybil}). For Fenfire, one
 security related problem occurs when user wants to perform global data lookup 
with a given
-pointer random string; how user is able to verify the correctness
+pointer random string; how the user is able to verify the correctness
 of the search results, and how do we know which one is the 
 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
+mentioned problem; data lookup is performed by user, but there is no reply
+from the system. How we are able to know if this was a spam attack, or the
 data really doesn't exist in the system ? Another problem related to Fenfire's 
 security is that if a user downloads data from the network to local computer 
 and after network disconnection, user wants to verify \emph{off line} the 
@@ -2049,7 +2050,7 @@
 hash \cite{fips-sha-1}. As the authors of \cite{balakrishnan03semanticfree},
 we also agree that tightly structured overlays provide general purpose
 interface to next-generation reference resolution services. Third, by using 
-DOLR abstraction of tightly structured overlay, we can minimize the the lack 
+DOLR abstraction of tightly structured overlay, we can minimize 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.
@@ -2061,13 +2062,11 @@
 blocks \emph{directly} from the network. Techniques used in distributed 
 database systems may prove to be useful. Some fundamental results
 regarding Peer-to-Peer and database systems has already been
-presented \cite{gribble01p2pdatabase}. 
+presented \cite{gribble01p2pdatabase}.  
 
-As security technologies comes more mature, we wish to apply these 
-technologies with Fenfire, if applicable.
-
-In the following months, we will implement a Fenfire Peer-to-Peer 
-prototype. 
+As security technologies come more mature, we wish to apply these 
+technologies with Fenfire, if applicable. In the following months, we will 
+implement a Fenfire Peer-to-Peer prototype. 
 
 \bibliographystyle{gradu}
 \bibliography{progradu}




reply via email to

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