[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/13 09:06:41

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

Log message:
        More corrections

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/Documentation/misc/hemppah-progradu/masterthesis.tex.diff?tr1=1.142&tr2=1.143&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/Documentation/misc/hemppah-progradu/storm_query_blockid.eps.diff?tr1=1.3&tr2=1.4&r1=text&r2=text

Patches:
Index: gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
diff -u gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.142 
gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.143
--- gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.142      Thu Mar 
13 08:47:15 2003
+++ gzz/Documentation/misc/hemppah-progradu/masterthesis.tex    Thu Mar 13 
09:06:35 2003
@@ -237,7 +237,7 @@
 forwards the query to their neighbors. This leads to a situation where number 
of messages
 in the network can grow with $O(n^{2})$, where $n$ is the number of 
participating peers in
 Gnutella network. To limit the amount of network traffic, Gnutella uses 
Time-To-Live-limited
-(TTL) flooding to distributed queries. Therefore, Gnutella uses a 
Breadth-First-Search (BFS) algorithm
+(TTL) flooding to distribute queries. Therefore, Gnutella uses a 
Breadth-First-Search (BFS) algorithm
 with depth limit $T$ (e.g., 7), where $T$ is the system-wide maximum TTL of a 
message in hops. Thus, 
 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 
@@ -334,7 +334,7 @@
 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 the overlay.
 While there are significant differences among proposed systems, they all have 
in common
-that \emph{peer identifiers} is assigned to participating peers from
+that \emph{peer identifiers} are 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
@@ -366,7 +366,7 @@
 peer identifier is gradually ''closer'' to the key's identifier
 in the identifier space. Distance can be measured by numerical
 difference between identifiers (e.g., Chord \cite{stoica01chord}), the number 
of
-same prefix bits between identifiers (e.g., Pastry \cite{rowston01pastry} and 
Tapestry \cite{zhao01tapestry}),
+same prefix bits between identifiers (e.g., Pastry \cite{rowston01pastry} and 
Tapestry \cite{zhao01tapestry}) or
 bit-wise exclusive or (XOR) (e.g., Kademlia \cite{maymounkov02kademlia}).
 Because of XOR-metric, Kademlia's distance function is both unidirectional
 (for a given point $p_i$ in the identifier space and distance $d$ > 0, there
@@ -387,7 +387,7 @@
 overlay, but in which queries are routed  to \emph{keys}. In these systems
 peer occupies several positions in the identifier space, one for each 
 application-specific key. The indirection of placing close keys in the 
-custody of a storing peer\footnote{Storing peer is the peer in the overlay 
which stores the
+custody of a storing peer\footnote{Storing peer is the peer in the overlay 
which is responsible for the
 assigned keys.} keys is removed at the cost of each peer maintaining one 
 ''resource peer'' in the overlay network for each resource item pair it 
publishes.
 
@@ -588,7 +588,7 @@
 \\ \hline
 
 \parbox{90pt}{Construction and maintenance of overlay} &
-\parbox{100pt}{uncontrolled and ad hoc}  &
+\parbox{100pt}{Uncontrolled and ad hoc}  &
 \parbox{100pt}{Controlled and structured}
 \\ \hline
                  
@@ -2016,11 +2016,7 @@
 \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 overlays. We have discussed differences, 
-disadvantages and advantages of both approaches.
-
-After that, we summarized open problems in Peer-to-Peer networks. Specifically,
+their properties.  We summarized open problems in Peer-to-Peer networks. 
Specifically,
 we divided open problems into three sub-categories: security related problems,
 performance related problems and miscellaneous problems. Each of these
 sub-categories have number of open problems, in which there are no solutions
@@ -2031,8 +2027,8 @@
 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
+In the last chapter, we evaluated existing Peer-to-Peer approaches with regard
+to Fenfire's needs. We proposed that tightly structured approach is the
 best alternative to Fenfire's 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 \emph{semantic-free 
references} 
@@ -2042,7 +2038,7 @@
 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 lack 
-of locality in tightly structured overlays. Finally, we believe that issues 
+of locality in tightly structured approach. 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/storm_query_blockid.eps
diff -u gzz/Documentation/misc/hemppah-progradu/storm_query_blockid.eps:1.3 
gzz/Documentation/misc/hemppah-progradu/storm_query_blockid.eps:1.4
--- gzz/Documentation/misc/hemppah-progradu/storm_query_blockid.eps:1.3 Thu Mar 
13 04:55:53 2003
+++ gzz/Documentation/misc/hemppah-progradu/storm_query_blockid.eps     Thu Mar 
13 09:06:37 2003
@@ -1,11 +1,11 @@
 %!PS-Adobe-2.0 EPSF-2.0
 %%Title: storm_query_blockid.dia
 %%Creator: Dia v0.90
-%%CreationDate: Thu Mar 13 11:47:28 2003
+%%CreationDate: Thu Mar 13 16:01:01 2003
 %%For: a user
 %%Magnification: 1.0000
 %%Orientation: Portrait
-%%BoundingBox: 0 0 638 437
+%%BoundingBox: 0 0 638 432
 %%Pages: 1
 %%EndComments
 %%BeginProlog
@@ -77,7 +77,7 @@
 %%BeginSetup
 %%EndSetup
 28.346000 -28.346000 scale
--2.559400 -16.809410 translate
+-2.559400 -16.709410 translate
 
 1.000000 1.000000 1.000000 srgb
 n 3.752970 7.709380 1.000000 1.000000 0 360 ellipse f
@@ -139,7 +139,7 @@
  /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi
  /P /o /i /n /t /e /r /F /xi /xi /d /space /S /m /b /l
  /c /k /colon /y /equal /I /D /one /period /Q /u /s /two /w /a /four
- /p /g /five /R /quotesingle /six /h /O /three /xi /xi /xi /xi /xi /xi /xi
+ /p /g /five /R /h /f /six /O /three /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 /xi /xi /xi
  /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi
@@ -191,12 +191,12 @@
 [0.200000] 0 sd
 [0.200000] 0 sd
 0 slc
-n 8.056077 7.899465 3.684088 3.684088 355.266662 57.980663 ellipse s
+n 8.056059 7.899466 3.684105 3.684105 355.266671 57.980516 ellipse s
 0 slj
-n 10.475613 10.259778 m 10.009400 11.023090 l 10.899778 10.938073 l f
+n 10.475611 10.259787 m 10.009400 11.023100 l 10.899777 10.938081 l f
 /Helvetica_e0 ff 0.700000 scf sf
 (<8+'!&=>&*;) sw
-2 div 14.009900 ex sub 10.295670 m (<8+'!&=>&*;)
+2 div 14.009900 ex sub 10.295700 m (<8+'!&=>&*;)
  gs 1 -1 sc sh gr
 /Helvetica_e0 ff 0.700000 scf sf
 (?8+'"#*;+*>$>+/!!1:@+$>&A%$) sw
@@ -206,13 +206,15 @@
 [0.200000] 0 sd
 [0.200000] 0 sd
 0 slc
-n 15.449867 16.170176 12.188266 12.188266 199.461351 278.293735 ellipse s
+n 15.449868 16.170177 12.188267 12.188267 199.461355 278.293731 ellipse s
 0 slj
 n 16.358668 4.389798 m 17.208000 4.109380 l 16.474066 3.598165 l f
-6.083310 9.150000 m /Helvetica_e0 ff 0.700000 scf sf
-(B8+C%$:&#+!=#%&D;)
+6.083310 8.850000 m /Helvetica_e0 ff 0.700000 scf sf
+(B8+C%$:&#+$D%)
  gs 1 -1 sc sh gr
-6.083310 9.850000 m (>**&%;;)
+6.083310 9.550000 m (>**&%;;+!E+;0&!//)
+ gs 1 -1 sc sh gr
+6.083310 10.250000 m (./!01+!=#%&)
  gs 1 -1 sc sh gr
 0.100000 slw
 [0.200000] 0 sd
@@ -222,8 +224,8 @@
 0 slj
 n 8.248989 3.015492 m 7.752370 3.759380 l 8.645452 3.710343 l f
 /Helvetica_e0 ff 0.700000 scf sf
-(E8+'%$0F+,$!&-+./!01) sw
-2 div 12.902400 ex sub 2.009380 m (E8+'%$0F+,$!&-+./!01)
+(F8+'%$0D+,$!&-+./!01) sw
+2 div 12.902400 ex sub 2.009380 m (F8+'%$0D+,$!&-+./!01)
  gs 1 -1 sc sh gr
 /Helvetica_e0 ff 0.700000 scf sf
 (G=#%&) sw