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 applica...


From: Hermanni Hyytiälä
Subject: [Gzz-commits] gzz/Documentation/misc/hemppah-progradu applica...
Date: Mon, 17 Mar 2003 10:07:39 -0500

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Hermanni Hyytiälä <address@hidden>      03/03/17 10:07:39

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

Log message:
        Lot of updates

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

Patches:
Index: gzz/Documentation/misc/hemppah-progradu/application_level_overlay.eps
diff -u 
gzz/Documentation/misc/hemppah-progradu/application_level_overlay.eps:1.3 
gzz/Documentation/misc/hemppah-progradu/application_level_overlay.eps:1.4
--- gzz/Documentation/misc/hemppah-progradu/application_level_overlay.eps:1.3   
Thu Mar 13 04:55:50 2003
+++ gzz/Documentation/misc/hemppah-progradu/application_level_overlay.eps       
Mon Mar 17 10:07:39 2003
@@ -1,11 +1,11 @@
 %!PS-Adobe-2.0 EPSF-2.0
 %%Title: application_level_overlay.dia
 %%Creator: Dia v0.90
-%%CreationDate: Thu Mar 13 11:08:51 2003
+%%CreationDate: Mon Mar 17 17:06:48 2003
 %%For: a user
 %%Magnification: 1.0000
 %%Orientation: Portrait
-%%BoundingBox: 0 0 386 332
+%%BoundingBox: 0 0 397 332
 %%Pages: 1
 %%EndComments
 %%BeginProlog
@@ -77,7 +77,7 @@
 %%BeginSetup
 %%EndSetup
 17.007601 -17.007601 scale
--2.123061 -19.450010 translate
+-2.123060 -19.450010 translate
 
 0.100000 slw
 [] 0 sd
@@ -89,26 +89,26 @@
 0 slj
 [] 0 sd
 0.701961 0.701961 0.701961 srgb
-n 6.111919 6.018920 m 6.111919 7.913672 l 6.923955 7.913672 l 6.923955 
6.018920 l f
+n 6.111918 6.018919 m 6.111918 7.913674 l 6.923956 7.913674 l 6.923956 
6.018919 l f
 0.000000 0.000000 0.000000 srgb
-n 6.111919 6.018920 m 6.111919 7.913672 l 6.923955 7.913672 l 6.923955 
6.018920 l cp s
+n 6.111918 6.018919 m 6.111918 7.913674 l 6.923956 7.913674 l 6.923956 
6.018919 l cp s
 0.010000 slw
 0 slc
 0 slj
 [] 0 sd
-n 6.193122 6.132605 m 6.193122 6.349148 l 6.842752 6.349148 l 6.842752 
6.132605 l cp s
+n 6.193122 6.132604 m 6.193122 6.349148 l 6.842752 6.349148 l 6.842752 
6.132604 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 6.193122 6.349148 m 6.193122 6.565692 l 6.842752 6.565692 l 6.842752 
6.349148 l cp s
+n 6.193122 6.349148 m 6.193122 6.565691 l 6.842752 6.565691 l 6.842752 
6.349148 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 6.193122 6.565692 m 6.193122 6.782235 l 6.842752 6.782235 l 6.842752 
6.565692 l cp s
+n 6.193122 6.565691 m 6.193122 6.782234 l 6.842752 6.782234 l 6.842752 
6.565691 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 6.193122 6.782235 m 6.193122 6.998778 l 6.842752 6.998778 l 6.842752 
6.782235 l cp s
+n 6.193122 6.782234 m 6.193122 6.998778 l 6.842752 6.998778 l 6.842752 
6.782234 l cp s
 0 slc
 0 slj
 [] 0 sd
@@ -137,34 +137,34 @@
 0 slc
 0 slj
 [] 0 sd
-n 6.247258 7.345247 m 6.247258 7.818935 l s
+n 6.247258 7.345247 m 6.247258 7.818936 l s
 0 slc
 0 slj
 [] 0 sd
-n 6.382598 7.345247 m 6.382598 7.818935 l s
+n 6.382597 7.345247 m 6.382597 7.818936 l s
 0 slc
 0 slj
 [] 0 sd
-n 6.517937 7.345247 m 6.517937 7.818935 l s
+n 6.517937 7.345247 m 6.517937 7.818936 l s
 0 slc
 0 slj
 [] 0 sd
-n 6.653277 7.345247 m 6.653277 7.818935 l s
+n 6.653277 7.345247 m 6.653277 7.818936 l s
 0 slc
 0 slj
 [] 0 sd
-n 6.788616 7.345247 m 6.788616 7.818935 l s
+n 6.788616 7.345247 m 6.788616 7.818936 l s
 0 slc
 0 slj
 [] 0 sd
-n 6.923955 7.345247 m 6.923955 7.818935 l s
+n 6.923956 7.345247 m 6.923956 7.818936 l s
 0 slc
 0 slj
 [] 0 sd
 0.600000 0.600000 0.600000 srgb
-n 5.949511 8.076080 m 6.111919 7.751265 l 6.111919 7.913672 l 6.923955 
7.913672 l 6.923955 7.751265 l 7.140499 8.076080 l f
+n 5.949511 8.076081 m 6.111918 7.751266 l 6.111918 7.913674 l 6.923956 
7.913674 l 6.923956 7.751266 l 7.140499 8.076081 l f
 0.000000 0.000000 0.000000 srgb
-n 5.949511 8.076080 m 6.111919 7.751265 l 6.111919 7.913672 l 6.923955 
7.913672 l 6.923955 7.751265 l 7.140499 8.076080 l cp s
+n 5.949511 8.076081 m 6.111918 7.751266 l 6.111918 7.913674 l 6.923956 
7.913674 l 6.923956 7.751266 l 7.140499 8.076081 l cp s
 0.100000 slw
 [] 0 sd
 [] 0 sd
@@ -175,26 +175,26 @@
 0 slj
 [] 0 sd
 0.701961 0.701961 0.701961 srgb
-n 2.493559 1.818920 m 2.493559 3.713672 l 3.305595 3.713672 l 3.305595 
1.818920 l f
+n 2.493558 1.818919 m 2.493558 3.713674 l 3.305596 3.713674 l 3.305596 
1.818919 l f
 0.000000 0.000000 0.000000 srgb
-n 2.493559 1.818920 m 2.493559 3.713672 l 3.305595 3.713672 l 3.305595 
1.818920 l cp s
+n 2.493558 1.818919 m 2.493558 3.713674 l 3.305596 3.713674 l 3.305596 
1.818919 l cp s
 0.010000 slw
 0 slc
 0 slj
 [] 0 sd
-n 2.574762 1.932605 m 2.574762 2.149148 l 3.224392 2.149148 l 3.224392 
1.932605 l cp s
+n 2.574762 1.932604 m 2.574762 2.149148 l 3.224392 2.149148 l 3.224392 
1.932604 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 2.574762 2.149148 m 2.574762 2.365692 l 3.224392 2.365692 l 3.224392 
2.149148 l cp s
+n 2.574762 2.149148 m 2.574762 2.365691 l 3.224392 2.365691 l 3.224392 
2.149148 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 2.574762 2.365692 m 2.574762 2.582235 l 3.224392 2.582235 l 3.224392 
2.365692 l cp s
+n 2.574762 2.365691 m 2.574762 2.582234 l 3.224392 2.582234 l 3.224392 
2.365691 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 2.574762 2.582235 m 2.574762 2.798778 l 3.224392 2.798778 l 3.224392 
2.582235 l cp s
+n 2.574762 2.582234 m 2.574762 2.798778 l 3.224392 2.798778 l 3.224392 
2.582234 l cp s
 0 slc
 0 slj
 [] 0 sd
@@ -223,34 +223,34 @@
 0 slc
 0 slj
 [] 0 sd
-n 2.628898 3.145247 m 2.628898 3.618935 l s
+n 2.628898 3.145247 m 2.628898 3.618936 l s
 0 slc
 0 slj
 [] 0 sd
-n 2.764238 3.145247 m 2.764238 3.618935 l s
+n 2.764237 3.145247 m 2.764237 3.618936 l s
 0 slc
 0 slj
 [] 0 sd
-n 2.899577 3.145247 m 2.899577 3.618935 l s
+n 2.899577 3.145247 m 2.899577 3.618936 l s
 0 slc
 0 slj
 [] 0 sd
-n 3.034917 3.145247 m 3.034917 3.618935 l s
+n 3.034917 3.145247 m 3.034917 3.618936 l s
 0 slc
 0 slj
 [] 0 sd
-n 3.170256 3.145247 m 3.170256 3.618935 l s
+n 3.170256 3.145247 m 3.170256 3.618936 l s
 0 slc
 0 slj
 [] 0 sd
-n 3.305595 3.145247 m 3.305595 3.618935 l s
+n 3.305596 3.145247 m 3.305596 3.618936 l s
 0 slc
 0 slj
 [] 0 sd
 0.600000 0.600000 0.600000 srgb
-n 2.331151 3.876080 m 2.493559 3.551265 l 2.493559 3.713672 l 3.305595 
3.713672 l 3.305595 3.551265 l 3.522139 3.876080 l f
+n 2.331151 3.876081 m 2.493558 3.551266 l 2.493558 3.713674 l 3.305596 
3.713674 l 3.305596 3.551266 l 3.522139 3.876081 l f
 0.000000 0.000000 0.000000 srgb
-n 2.331151 3.876080 m 2.493559 3.551265 l 2.493559 3.713672 l 3.305595 
3.713672 l 3.305595 3.551265 l 3.522139 3.876080 l cp s
+n 2.331151 3.876081 m 2.493558 3.551266 l 2.493558 3.713674 l 3.305596 
3.713674 l 3.305596 3.551266 l 3.522139 3.876081 l cp s
 0.100000 slw
 [] 0 sd
 [] 0 sd
@@ -261,82 +261,82 @@
 0 slj
 [] 0 sd
 0.701961 0.701961 0.701961 srgb
-n 18.843559 1.868920 m 18.843559 3.763672 l 19.655595 3.763672 l 19.655595 
1.868920 l f
+n 18.843608 1.868919 m 18.843608 3.763674 l 19.655646 3.763674 l 19.655646 
1.868919 l f
 0.000000 0.000000 0.000000 srgb
-n 18.843559 1.868920 m 18.843559 3.763672 l 19.655595 3.763672 l 19.655595 
1.868920 l cp s
+n 18.843608 1.868919 m 18.843608 3.763674 l 19.655646 3.763674 l 19.655646 
1.868919 l cp s
 0.010000 slw
 0 slc
 0 slj
 [] 0 sd
-n 18.924762 1.982605 m 18.924762 2.199148 l 19.574392 2.199148 l 19.574392 
1.982605 l cp s
+n 18.924812 1.982604 m 18.924812 2.199148 l 19.574442 2.199148 l 19.574442 
1.982604 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 18.924762 2.199148 m 18.924762 2.415692 l 19.574392 2.415692 l 19.574392 
2.199148 l cp s
+n 18.924812 2.199148 m 18.924812 2.415691 l 19.574442 2.415691 l 19.574442 
2.199148 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 18.924762 2.415692 m 18.924762 2.632235 l 19.574392 2.632235 l 19.574392 
2.415692 l cp s
+n 18.924812 2.415691 m 18.924812 2.632234 l 19.574442 2.632234 l 19.574442 
2.415691 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 18.924762 2.632235 m 18.924762 2.848778 l 19.574392 2.848778 l 19.574392 
2.632235 l cp s
+n 18.924812 2.632234 m 18.924812 2.848778 l 19.574442 2.848778 l 19.574442 
2.632234 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 18.924762 2.892086 m 18.924762 3.022012 l 19.330781 3.022012 l 19.330781 
2.892086 l cp s
+n 18.924812 2.892086 m 18.924812 3.022012 l 19.330831 3.022012 l 19.330831 
2.892086 l cp s
 0 slc
 0 slj
 [] 0 sd
 0.000000 1.000000 0.000000 srgb
-n 19.533790 2.913741 0.028421 0.028421 0 360 ellipse f
+n 19.533840 2.913741 0.028421 0.028421 0 360 ellipse f
 0.000000 0.000000 0.000000 srgb
-n 19.533790 2.913741 0.028421 0.028421 0 360 ellipse cp s
+n 19.533840 2.913741 0.028421 0.028421 0 360 ellipse cp s
 0 slc
 0 slj
 [] 0 sd
 1.000000 1.000000 0.000000 srgb
-n 19.533790 3.000358 0.028421 0.028421 0 360 ellipse f
+n 19.533840 3.000358 0.028421 0.028421 0 360 ellipse f
 0.000000 0.000000 0.000000 srgb
-n 19.533790 3.000358 0.028421 0.028421 0 360 ellipse cp s
+n 19.533840 3.000358 0.028421 0.028421 0 360 ellipse cp s
 0 slc
 0 slj
 [] 0 sd
 1.000000 1.000000 1.000000 srgb
-n 19.371383 2.935395 m 19.371383 3.022012 l 19.468827 3.022012 l 19.468827 
2.935395 l f
+n 19.371433 2.935395 m 19.371433 3.022012 l 19.468877 3.022012 l 19.468877 
2.935395 l f
 0.000000 0.000000 0.000000 srgb
-n 19.371383 2.935395 m 19.371383 3.022012 l 19.468827 3.022012 l 19.468827 
2.935395 l cp s
+n 19.371433 2.935395 m 19.371433 3.022012 l 19.468877 3.022012 l 19.468877 
2.935395 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 18.978898 3.195247 m 18.978898 3.668935 l s
+n 18.978948 3.195247 m 18.978948 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
-n 19.114238 3.195247 m 19.114238 3.668935 l s
+n 19.114287 3.195247 m 19.114287 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
-n 19.249577 3.195247 m 19.249577 3.668935 l s
+n 19.249627 3.195247 m 19.249627 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
-n 19.384917 3.195247 m 19.384917 3.668935 l s
+n 19.384967 3.195247 m 19.384967 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
-n 19.520256 3.195247 m 19.520256 3.668935 l s
+n 19.520306 3.195247 m 19.520306 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
-n 19.655595 3.195247 m 19.655595 3.668935 l s
+n 19.655646 3.195247 m 19.655646 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
 0.600000 0.600000 0.600000 srgb
-n 18.681151 3.926080 m 18.843559 3.601265 l 18.843559 3.763672 l 19.655595 
3.763672 l 19.655595 3.601265 l 19.872139 3.926080 l f
+n 18.681201 3.926081 m 18.843608 3.601266 l 18.843608 3.763674 l 19.655646 
3.763674 l 19.655646 3.601266 l 19.872189 3.926081 l f
 0.000000 0.000000 0.000000 srgb
-n 18.681151 3.926080 m 18.843559 3.601265 l 18.843559 3.763672 l 19.655595 
3.763672 l 19.655595 3.601265 l 19.872139 3.926080 l cp s
+n 18.681201 3.926081 m 18.843608 3.601266 l 18.843608 3.763674 l 19.655646 
3.763674 l 19.655646 3.601266 l 19.872189 3.926081 l cp s
 0.100000 slw
 [] 0 sd
 [] 0 sd
@@ -347,82 +347,82 @@
 0 slj
 [] 0 sd
 0.701961 0.701961 0.701961 srgb
-n 15.193559 10.818920 m 15.193559 12.713672 l 16.005595 12.713672 l 16.005595 
10.818920 l f
+n 15.193608 10.818899 m 15.193608 12.713654 l 16.005646 12.713654 l 16.005646 
10.818899 l f
 0.000000 0.000000 0.000000 srgb
-n 15.193559 10.818920 m 15.193559 12.713672 l 16.005595 12.713672 l 16.005595 
10.818920 l cp s
+n 15.193608 10.818899 m 15.193608 12.713654 l 16.005646 12.713654 l 16.005646 
10.818899 l cp s
 0.010000 slw
 0 slc
 0 slj
 [] 0 sd
-n 15.274762 10.932605 m 15.274762 11.149148 l 15.924392 11.149148 l 15.924392 
10.932605 l cp s
+n 15.274812 10.932584 m 15.274812 11.149128 l 15.924442 11.149128 l 15.924442 
10.932584 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 15.274762 11.149148 m 15.274762 11.365692 l 15.924392 11.365692 l 15.924392 
11.149148 l cp s
+n 15.274812 11.149128 m 15.274812 11.365671 l 15.924442 11.365671 l 15.924442 
11.149128 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 15.274762 11.365692 m 15.274762 11.582235 l 15.924392 11.582235 l 15.924392 
11.365692 l cp s
+n 15.274812 11.365671 m 15.274812 11.582214 l 15.924442 11.582214 l 15.924442 
11.365671 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 15.274762 11.582235 m 15.274762 11.798778 l 15.924392 11.798778 l 15.924392 
11.582235 l cp s
+n 15.274812 11.582214 m 15.274812 11.798758 l 15.924442 11.798758 l 15.924442 
11.582214 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 15.274762 11.842086 m 15.274762 11.972012 l 15.680781 11.972012 l 15.680781 
11.842086 l cp s
+n 15.274812 11.842066 m 15.274812 11.971992 l 15.680831 11.971992 l 15.680831 
11.842066 l cp s
 0 slc
 0 slj
 [] 0 sd
 0.000000 1.000000 0.000000 srgb
-n 15.883790 11.863741 0.028421 0.028421 0 360 ellipse f
+n 15.883840 11.863721 0.028421 0.028421 0 360 ellipse f
 0.000000 0.000000 0.000000 srgb
-n 15.883790 11.863741 0.028421 0.028421 0 360 ellipse cp s
+n 15.883840 11.863721 0.028421 0.028421 0 360 ellipse cp s
 0 slc
 0 slj
 [] 0 sd
 1.000000 1.000000 0.000000 srgb
-n 15.883790 11.950358 0.028421 0.028421 0 360 ellipse f
+n 15.883840 11.950338 0.028421 0.028421 0 360 ellipse f
 0.000000 0.000000 0.000000 srgb
-n 15.883790 11.950358 0.028421 0.028421 0 360 ellipse cp s
+n 15.883840 11.950338 0.028421 0.028421 0 360 ellipse cp s
 0 slc
 0 slj
 [] 0 sd
 1.000000 1.000000 1.000000 srgb
-n 15.721383 11.885395 m 15.721383 11.972012 l 15.818827 11.972012 l 15.818827 
11.885395 l f
+n 15.721433 11.885375 m 15.721433 11.971992 l 15.818877 11.971992 l 15.818877 
11.885375 l f
 0.000000 0.000000 0.000000 srgb
-n 15.721383 11.885395 m 15.721383 11.972012 l 15.818827 11.972012 l 15.818827 
11.885395 l cp s
+n 15.721433 11.885375 m 15.721433 11.971992 l 15.818877 11.971992 l 15.818877 
11.885375 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 15.328898 12.145247 m 15.328898 12.618935 l s
+n 15.328948 12.145227 m 15.328948 12.618916 l s
 0 slc
 0 slj
 [] 0 sd
-n 15.464238 12.145247 m 15.464238 12.618935 l s
+n 15.464287 12.145227 m 15.464287 12.618916 l s
 0 slc
 0 slj
 [] 0 sd
-n 15.599577 12.145247 m 15.599577 12.618935 l s
+n 15.599627 12.145227 m 15.599627 12.618916 l s
 0 slc
 0 slj
 [] 0 sd
-n 15.734917 12.145247 m 15.734917 12.618935 l s
+n 15.734967 12.145227 m 15.734967 12.618916 l s
 0 slc
 0 slj
 [] 0 sd
-n 15.870256 12.145247 m 15.870256 12.618935 l s
+n 15.870306 12.145227 m 15.870306 12.618916 l s
 0 slc
 0 slj
 [] 0 sd
-n 16.005595 12.145247 m 16.005595 12.618935 l s
+n 16.005646 12.145227 m 16.005646 12.618916 l s
 0 slc
 0 slj
 [] 0 sd
 0.600000 0.600000 0.600000 srgb
-n 15.031151 12.876080 m 15.193559 12.551265 l 15.193559 12.713672 l 16.005595 
12.713672 l 16.005595 12.551265 l 16.222139 12.876080 l f
+n 15.031201 12.876061 m 15.193608 12.551246 l 15.193608 12.713654 l 16.005646 
12.713654 l 16.005646 12.551246 l 16.222189 12.876061 l f
 0.000000 0.000000 0.000000 srgb
-n 15.031151 12.876080 m 15.193559 12.551265 l 15.193559 12.713672 l 16.005595 
12.713672 l 16.005595 12.551265 l 16.222139 12.876080 l cp s
+n 15.031201 12.876061 m 15.193608 12.551246 l 15.193608 12.713654 l 16.005646 
12.713654 l 16.005646 12.551246 l 16.222189 12.876061 l cp s
 0.100000 slw
 [] 0 sd
 [] 0 sd
@@ -433,82 +433,82 @@
 0 slj
 [] 0 sd
 0.701961 0.701961 0.701961 srgb
-n 22.243559 1.868920 m 22.243559 3.763672 l 23.055595 3.763672 l 23.055595 
1.868920 l f
+n 22.243608 1.868919 m 22.243608 3.763674 l 23.055646 3.763674 l 23.055646 
1.868919 l f
 0.000000 0.000000 0.000000 srgb
-n 22.243559 1.868920 m 22.243559 3.763672 l 23.055595 3.763672 l 23.055595 
1.868920 l cp s
+n 22.243608 1.868919 m 22.243608 3.763674 l 23.055646 3.763674 l 23.055646 
1.868919 l cp s
 0.010000 slw
 0 slc
 0 slj
 [] 0 sd
-n 22.324762 1.982605 m 22.324762 2.199148 l 22.974392 2.199148 l 22.974392 
1.982605 l cp s
+n 22.324812 1.982604 m 22.324812 2.199148 l 22.974442 2.199148 l 22.974442 
1.982604 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 22.324762 2.199148 m 22.324762 2.415692 l 22.974392 2.415692 l 22.974392 
2.199148 l cp s
+n 22.324812 2.199148 m 22.324812 2.415691 l 22.974442 2.415691 l 22.974442 
2.199148 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 22.324762 2.415692 m 22.324762 2.632235 l 22.974392 2.632235 l 22.974392 
2.415692 l cp s
+n 22.324812 2.415691 m 22.324812 2.632234 l 22.974442 2.632234 l 22.974442 
2.415691 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 22.324762 2.632235 m 22.324762 2.848778 l 22.974392 2.848778 l 22.974392 
2.632235 l cp s
+n 22.324812 2.632234 m 22.324812 2.848778 l 22.974442 2.848778 l 22.974442 
2.632234 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 22.324762 2.892086 m 22.324762 3.022012 l 22.730781 3.022012 l 22.730781 
2.892086 l cp s
+n 22.324812 2.892086 m 22.324812 3.022012 l 22.730831 3.022012 l 22.730831 
2.892086 l cp s
 0 slc
 0 slj
 [] 0 sd
 0.000000 1.000000 0.000000 srgb
-n 22.933790 2.913741 0.028421 0.028421 0 360 ellipse f
+n 22.933840 2.913741 0.028421 0.028421 0 360 ellipse f
 0.000000 0.000000 0.000000 srgb
-n 22.933790 2.913741 0.028421 0.028421 0 360 ellipse cp s
+n 22.933840 2.913741 0.028421 0.028421 0 360 ellipse cp s
 0 slc
 0 slj
 [] 0 sd
 1.000000 1.000000 0.000000 srgb
-n 22.933790 3.000358 0.028421 0.028421 0 360 ellipse f
+n 22.933840 3.000358 0.028421 0.028421 0 360 ellipse f
 0.000000 0.000000 0.000000 srgb
-n 22.933790 3.000358 0.028421 0.028421 0 360 ellipse cp s
+n 22.933840 3.000358 0.028421 0.028421 0 360 ellipse cp s
 0 slc
 0 slj
 [] 0 sd
 1.000000 1.000000 1.000000 srgb
-n 22.771383 2.935395 m 22.771383 3.022012 l 22.868827 3.022012 l 22.868827 
2.935395 l f
+n 22.771433 2.935395 m 22.771433 3.022012 l 22.868877 3.022012 l 22.868877 
2.935395 l f
 0.000000 0.000000 0.000000 srgb
-n 22.771383 2.935395 m 22.771383 3.022012 l 22.868827 3.022012 l 22.868827 
2.935395 l cp s
+n 22.771433 2.935395 m 22.771433 3.022012 l 22.868877 3.022012 l 22.868877 
2.935395 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 22.378898 3.195247 m 22.378898 3.668935 l s
+n 22.378948 3.195247 m 22.378948 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
-n 22.514238 3.195247 m 22.514238 3.668935 l s
+n 22.514287 3.195247 m 22.514287 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
-n 22.649577 3.195247 m 22.649577 3.668935 l s
+n 22.649627 3.195247 m 22.649627 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
-n 22.784917 3.195247 m 22.784917 3.668935 l s
+n 22.784967 3.195247 m 22.784967 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
-n 22.920256 3.195247 m 22.920256 3.668935 l s
+n 22.920306 3.195247 m 22.920306 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
-n 23.055595 3.195247 m 23.055595 3.668935 l s
+n 23.055646 3.195247 m 23.055646 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
 0.600000 0.600000 0.600000 srgb
-n 22.081151 3.926080 m 22.243559 3.601265 l 22.243559 3.763672 l 23.055595 
3.763672 l 23.055595 3.601265 l 23.272139 3.926080 l f
+n 22.081201 3.926081 m 22.243608 3.601266 l 22.243608 3.763674 l 23.055646 
3.763674 l 23.055646 3.601266 l 23.272189 3.926081 l f
 0.000000 0.000000 0.000000 srgb
-n 22.081151 3.926080 m 22.243559 3.601265 l 22.243559 3.763672 l 23.055595 
3.763672 l 23.055595 3.601265 l 23.272139 3.926080 l cp s
+n 22.081201 3.926081 m 22.243608 3.601266 l 22.243608 3.763674 l 23.055646 
3.763674 l 23.055646 3.601266 l 23.272189 3.926081 l cp s
 0.100000 slw
 [] 0 sd
 [] 0 sd
@@ -519,82 +519,82 @@
 0 slj
 [] 0 sd
 0.701961 0.701961 0.701961 srgb
-n 15.143559 1.868920 m 15.143559 3.763672 l 15.955595 3.763672 l 15.955595 
1.868920 l f
+n 15.143608 1.868919 m 15.143608 3.763674 l 15.955646 3.763674 l 15.955646 
1.868919 l f
 0.000000 0.000000 0.000000 srgb
-n 15.143559 1.868920 m 15.143559 3.763672 l 15.955595 3.763672 l 15.955595 
1.868920 l cp s
+n 15.143608 1.868919 m 15.143608 3.763674 l 15.955646 3.763674 l 15.955646 
1.868919 l cp s
 0.010000 slw
 0 slc
 0 slj
 [] 0 sd
-n 15.224762 1.982605 m 15.224762 2.199148 l 15.874392 2.199148 l 15.874392 
1.982605 l cp s
+n 15.224812 1.982604 m 15.224812 2.199148 l 15.874442 2.199148 l 15.874442 
1.982604 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 15.224762 2.199148 m 15.224762 2.415692 l 15.874392 2.415692 l 15.874392 
2.199148 l cp s
+n 15.224812 2.199148 m 15.224812 2.415691 l 15.874442 2.415691 l 15.874442 
2.199148 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 15.224762 2.415692 m 15.224762 2.632235 l 15.874392 2.632235 l 15.874392 
2.415692 l cp s
+n 15.224812 2.415691 m 15.224812 2.632234 l 15.874442 2.632234 l 15.874442 
2.415691 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 15.224762 2.632235 m 15.224762 2.848778 l 15.874392 2.848778 l 15.874392 
2.632235 l cp s
+n 15.224812 2.632234 m 15.224812 2.848778 l 15.874442 2.848778 l 15.874442 
2.632234 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 15.224762 2.892086 m 15.224762 3.022012 l 15.630781 3.022012 l 15.630781 
2.892086 l cp s
+n 15.224812 2.892086 m 15.224812 3.022012 l 15.630831 3.022012 l 15.630831 
2.892086 l cp s
 0 slc
 0 slj
 [] 0 sd
 0.000000 1.000000 0.000000 srgb
-n 15.833790 2.913741 0.028421 0.028421 0 360 ellipse f
+n 15.833840 2.913741 0.028421 0.028421 0 360 ellipse f
 0.000000 0.000000 0.000000 srgb
-n 15.833790 2.913741 0.028421 0.028421 0 360 ellipse cp s
+n 15.833840 2.913741 0.028421 0.028421 0 360 ellipse cp s
 0 slc
 0 slj
 [] 0 sd
 1.000000 1.000000 0.000000 srgb
-n 15.833790 3.000358 0.028421 0.028421 0 360 ellipse f
+n 15.833840 3.000358 0.028421 0.028421 0 360 ellipse f
 0.000000 0.000000 0.000000 srgb
-n 15.833790 3.000358 0.028421 0.028421 0 360 ellipse cp s
+n 15.833840 3.000358 0.028421 0.028421 0 360 ellipse cp s
 0 slc
 0 slj
 [] 0 sd
 1.000000 1.000000 1.000000 srgb
-n 15.671383 2.935395 m 15.671383 3.022012 l 15.768827 3.022012 l 15.768827 
2.935395 l f
+n 15.671433 2.935395 m 15.671433 3.022012 l 15.768877 3.022012 l 15.768877 
2.935395 l f
 0.000000 0.000000 0.000000 srgb
-n 15.671383 2.935395 m 15.671383 3.022012 l 15.768827 3.022012 l 15.768827 
2.935395 l cp s
+n 15.671433 2.935395 m 15.671433 3.022012 l 15.768877 3.022012 l 15.768877 
2.935395 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 15.278898 3.195247 m 15.278898 3.668935 l s
+n 15.278948 3.195247 m 15.278948 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
-n 15.414238 3.195247 m 15.414238 3.668935 l s
+n 15.414287 3.195247 m 15.414287 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
-n 15.549577 3.195247 m 15.549577 3.668935 l s
+n 15.549627 3.195247 m 15.549627 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
-n 15.684917 3.195247 m 15.684917 3.668935 l s
+n 15.684967 3.195247 m 15.684967 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
-n 15.820256 3.195247 m 15.820256 3.668935 l s
+n 15.820306 3.195247 m 15.820306 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
-n 15.955595 3.195247 m 15.955595 3.668935 l s
+n 15.955646 3.195247 m 15.955646 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
 0.600000 0.600000 0.600000 srgb
-n 14.981151 3.926080 m 15.143559 3.601265 l 15.143559 3.763672 l 15.955595 
3.763672 l 15.955595 3.601265 l 16.172139 3.926080 l f
+n 14.981201 3.926081 m 15.143608 3.601266 l 15.143608 3.763674 l 15.955646 
3.763674 l 15.955646 3.601266 l 16.172189 3.926081 l f
 0.000000 0.000000 0.000000 srgb
-n 14.981151 3.926080 m 15.143559 3.601265 l 15.143559 3.763672 l 15.955595 
3.763672 l 15.955595 3.601265 l 16.172139 3.926080 l cp s
+n 14.981201 3.926081 m 15.143608 3.601266 l 15.143608 3.763674 l 15.955646 
3.763674 l 15.955646 3.601266 l 16.172189 3.926081 l cp s
 0.100000 slw
 [] 0 sd
 [] 0 sd
@@ -605,82 +605,82 @@
 0 slj
 [] 0 sd
 0.701961 0.701961 0.701961 srgb
-n 18.993559 10.818920 m 18.993559 12.713672 l 19.805595 12.713672 l 19.805595 
10.818920 l f
+n 18.993608 10.818899 m 18.993608 12.713654 l 19.805646 12.713654 l 19.805646 
10.818899 l f
 0.000000 0.000000 0.000000 srgb
-n 18.993559 10.818920 m 18.993559 12.713672 l 19.805595 12.713672 l 19.805595 
10.818920 l cp s
+n 18.993608 10.818899 m 18.993608 12.713654 l 19.805646 12.713654 l 19.805646 
10.818899 l cp s
 0.010000 slw
 0 slc
 0 slj
 [] 0 sd
-n 19.074762 10.932605 m 19.074762 11.149148 l 19.724392 11.149148 l 19.724392 
10.932605 l cp s
+n 19.074812 10.932584 m 19.074812 11.149128 l 19.724442 11.149128 l 19.724442 
10.932584 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 19.074762 11.149148 m 19.074762 11.365692 l 19.724392 11.365692 l 19.724392 
11.149148 l cp s
+n 19.074812 11.149128 m 19.074812 11.365671 l 19.724442 11.365671 l 19.724442 
11.149128 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 19.074762 11.365692 m 19.074762 11.582235 l 19.724392 11.582235 l 19.724392 
11.365692 l cp s
+n 19.074812 11.365671 m 19.074812 11.582214 l 19.724442 11.582214 l 19.724442 
11.365671 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 19.074762 11.582235 m 19.074762 11.798778 l 19.724392 11.798778 l 19.724392 
11.582235 l cp s
+n 19.074812 11.582214 m 19.074812 11.798758 l 19.724442 11.798758 l 19.724442 
11.582214 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 19.074762 11.842086 m 19.074762 11.972012 l 19.480781 11.972012 l 19.480781 
11.842086 l cp s
+n 19.074812 11.842066 m 19.074812 11.971992 l 19.480831 11.971992 l 19.480831 
11.842066 l cp s
 0 slc
 0 slj
 [] 0 sd
 0.000000 1.000000 0.000000 srgb
-n 19.683790 11.863741 0.028421 0.028421 0 360 ellipse f
+n 19.683840 11.863721 0.028421 0.028421 0 360 ellipse f
 0.000000 0.000000 0.000000 srgb
-n 19.683790 11.863741 0.028421 0.028421 0 360 ellipse cp s
+n 19.683840 11.863721 0.028421 0.028421 0 360 ellipse cp s
 0 slc
 0 slj
 [] 0 sd
 1.000000 1.000000 0.000000 srgb
-n 19.683790 11.950358 0.028421 0.028421 0 360 ellipse f
+n 19.683840 11.950338 0.028421 0.028421 0 360 ellipse f
 0.000000 0.000000 0.000000 srgb
-n 19.683790 11.950358 0.028421 0.028421 0 360 ellipse cp s
+n 19.683840 11.950338 0.028421 0.028421 0 360 ellipse cp s
 0 slc
 0 slj
 [] 0 sd
 1.000000 1.000000 1.000000 srgb
-n 19.521383 11.885395 m 19.521383 11.972012 l 19.618827 11.972012 l 19.618827 
11.885395 l f
+n 19.521433 11.885375 m 19.521433 11.971992 l 19.618877 11.971992 l 19.618877 
11.885375 l f
 0.000000 0.000000 0.000000 srgb
-n 19.521383 11.885395 m 19.521383 11.972012 l 19.618827 11.972012 l 19.618827 
11.885395 l cp s
+n 19.521433 11.885375 m 19.521433 11.971992 l 19.618877 11.971992 l 19.618877 
11.885375 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 19.128898 12.145247 m 19.128898 12.618935 l s
+n 19.128948 12.145227 m 19.128948 12.618916 l s
 0 slc
 0 slj
 [] 0 sd
-n 19.264238 12.145247 m 19.264238 12.618935 l s
+n 19.264287 12.145227 m 19.264287 12.618916 l s
 0 slc
 0 slj
 [] 0 sd
-n 19.399577 12.145247 m 19.399577 12.618935 l s
+n 19.399627 12.145227 m 19.399627 12.618916 l s
 0 slc
 0 slj
 [] 0 sd
-n 19.534917 12.145247 m 19.534917 12.618935 l s
+n 19.534967 12.145227 m 19.534967 12.618916 l s
 0 slc
 0 slj
 [] 0 sd
-n 19.670256 12.145247 m 19.670256 12.618935 l s
+n 19.670306 12.145227 m 19.670306 12.618916 l s
 0 slc
 0 slj
 [] 0 sd
-n 19.805595 12.145247 m 19.805595 12.618935 l s
+n 19.805646 12.145227 m 19.805646 12.618916 l s
 0 slc
 0 slj
 [] 0 sd
 0.600000 0.600000 0.600000 srgb
-n 18.831151 12.876080 m 18.993559 12.551265 l 18.993559 12.713672 l 19.805595 
12.713672 l 19.805595 12.551265 l 20.022139 12.876080 l f
+n 18.831201 12.876061 m 18.993608 12.551246 l 18.993608 12.713654 l 19.805646 
12.713654 l 19.805646 12.551246 l 20.022189 12.876061 l f
 0.000000 0.000000 0.000000 srgb
-n 18.831151 12.876080 m 18.993559 12.551265 l 18.993559 12.713672 l 19.805595 
12.713672 l 19.805595 12.551265 l 20.022139 12.876080 l cp s
+n 18.831201 12.876061 m 18.993608 12.551246 l 18.993608 12.713654 l 19.805646 
12.713654 l 19.805646 12.551246 l 20.022189 12.876061 l cp s
 0.100000 slw
 [] 0 sd
 [] 0 sd
@@ -691,82 +691,82 @@
 0 slj
 [] 0 sd
 0.701961 0.701961 0.701961 srgb
-n 2.293559 10.768920 m 2.293559 12.663672 l 3.105595 12.663672 l 3.105595 
10.768920 l f
+n 2.293558 10.768899 m 2.293558 12.663654 l 3.105596 12.663654 l 3.105596 
10.768899 l f
 0.000000 0.000000 0.000000 srgb
-n 2.293559 10.768920 m 2.293559 12.663672 l 3.105595 12.663672 l 3.105595 
10.768920 l cp s
+n 2.293558 10.768899 m 2.293558 12.663654 l 3.105596 12.663654 l 3.105596 
10.768899 l cp s
 0.010000 slw
 0 slc
 0 slj
 [] 0 sd
-n 2.374762 10.882605 m 2.374762 11.099148 l 3.024392 11.099148 l 3.024392 
10.882605 l cp s
+n 2.374762 10.882584 m 2.374762 11.099128 l 3.024392 11.099128 l 3.024392 
10.882584 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 2.374762 11.099148 m 2.374762 11.315692 l 3.024392 11.315692 l 3.024392 
11.099148 l cp s
+n 2.374762 11.099128 m 2.374762 11.315671 l 3.024392 11.315671 l 3.024392 
11.099128 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 2.374762 11.315692 m 2.374762 11.532235 l 3.024392 11.532235 l 3.024392 
11.315692 l cp s
+n 2.374762 11.315671 m 2.374762 11.532214 l 3.024392 11.532214 l 3.024392 
11.315671 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 2.374762 11.532235 m 2.374762 11.748778 l 3.024392 11.748778 l 3.024392 
11.532235 l cp s
+n 2.374762 11.532214 m 2.374762 11.748758 l 3.024392 11.748758 l 3.024392 
11.532214 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 2.374762 11.792086 m 2.374762 11.922012 l 2.780781 11.922012 l 2.780781 
11.792086 l cp s
+n 2.374762 11.792066 m 2.374762 11.921992 l 2.780781 11.921992 l 2.780781 
11.792066 l cp s
 0 slc
 0 slj
 [] 0 sd
 0.000000 1.000000 0.000000 srgb
-n 2.983790 11.813741 0.028421 0.028421 0 360 ellipse f
+n 2.983790 11.813721 0.028421 0.028421 0 360 ellipse f
 0.000000 0.000000 0.000000 srgb
-n 2.983790 11.813741 0.028421 0.028421 0 360 ellipse cp s
+n 2.983790 11.813721 0.028421 0.028421 0 360 ellipse cp s
 0 slc
 0 slj
 [] 0 sd
 1.000000 1.000000 0.000000 srgb
-n 2.983790 11.900358 0.028421 0.028421 0 360 ellipse f
+n 2.983790 11.900338 0.028421 0.028421 0 360 ellipse f
 0.000000 0.000000 0.000000 srgb
-n 2.983790 11.900358 0.028421 0.028421 0 360 ellipse cp s
+n 2.983790 11.900338 0.028421 0.028421 0 360 ellipse cp s
 0 slc
 0 slj
 [] 0 sd
 1.000000 1.000000 1.000000 srgb
-n 2.821383 11.835395 m 2.821383 11.922012 l 2.918827 11.922012 l 2.918827 
11.835395 l f
+n 2.821383 11.835375 m 2.821383 11.921992 l 2.918827 11.921992 l 2.918827 
11.835375 l f
 0.000000 0.000000 0.000000 srgb
-n 2.821383 11.835395 m 2.821383 11.922012 l 2.918827 11.922012 l 2.918827 
11.835395 l cp s
+n 2.821383 11.835375 m 2.821383 11.921992 l 2.918827 11.921992 l 2.918827 
11.835375 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 2.428898 12.095247 m 2.428898 12.568935 l s
+n 2.428898 12.095227 m 2.428898 12.568916 l s
 0 slc
 0 slj
 [] 0 sd
-n 2.564238 12.095247 m 2.564238 12.568935 l s
+n 2.564237 12.095227 m 2.564237 12.568916 l s
 0 slc
 0 slj
 [] 0 sd
-n 2.699577 12.095247 m 2.699577 12.568935 l s
+n 2.699577 12.095227 m 2.699577 12.568916 l s
 0 slc
 0 slj
 [] 0 sd
-n 2.834917 12.095247 m 2.834917 12.568935 l s
+n 2.834917 12.095227 m 2.834917 12.568916 l s
 0 slc
 0 slj
 [] 0 sd
-n 2.970256 12.095247 m 2.970256 12.568935 l s
+n 2.970256 12.095227 m 2.970256 12.568916 l s
 0 slc
 0 slj
 [] 0 sd
-n 3.105595 12.095247 m 3.105595 12.568935 l s
+n 3.105596 12.095227 m 3.105596 12.568916 l s
 0 slc
 0 slj
 [] 0 sd
 0.600000 0.600000 0.600000 srgb
-n 2.131151 12.826080 m 2.293559 12.501265 l 2.293559 12.663672 l 3.105595 
12.663672 l 3.105595 12.501265 l 3.322139 12.826080 l f
+n 2.131151 12.826061 m 2.293558 12.501246 l 2.293558 12.663654 l 3.105596 
12.663654 l 3.105596 12.501246 l 3.322139 12.826061 l f
 0.000000 0.000000 0.000000 srgb
-n 2.131151 12.826080 m 2.293559 12.501265 l 2.293559 12.663672 l 3.105595 
12.663672 l 3.105595 12.501265 l 3.322139 12.826080 l cp s
+n 2.131151 12.826061 m 2.293558 12.501246 l 2.293558 12.663654 l 3.105596 
12.663654 l 3.105596 12.501246 l 3.322139 12.826061 l cp s
 0.100000 slw
 [] 0 sd
 [] 0 sd
@@ -777,82 +777,82 @@
 0 slj
 [] 0 sd
 0.701961 0.701961 0.701961 srgb
-n 5.993559 10.818920 m 5.993559 12.713672 l 6.805595 12.713672 l 6.805595 
10.818920 l f
+n 5.993558 10.818899 m 5.993558 12.713654 l 6.805596 12.713654 l 6.805596 
10.818899 l f
 0.000000 0.000000 0.000000 srgb
-n 5.993559 10.818920 m 5.993559 12.713672 l 6.805595 12.713672 l 6.805595 
10.818920 l cp s
+n 5.993558 10.818899 m 5.993558 12.713654 l 6.805596 12.713654 l 6.805596 
10.818899 l cp s
 0.010000 slw
 0 slc
 0 slj
 [] 0 sd
-n 6.074762 10.932605 m 6.074762 11.149148 l 6.724392 11.149148 l 6.724392 
10.932605 l cp s
+n 6.074762 10.932584 m 6.074762 11.149128 l 6.724392 11.149128 l 6.724392 
10.932584 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 6.074762 11.149148 m 6.074762 11.365692 l 6.724392 11.365692 l 6.724392 
11.149148 l cp s
+n 6.074762 11.149128 m 6.074762 11.365671 l 6.724392 11.365671 l 6.724392 
11.149128 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 6.074762 11.365692 m 6.074762 11.582235 l 6.724392 11.582235 l 6.724392 
11.365692 l cp s
+n 6.074762 11.365671 m 6.074762 11.582214 l 6.724392 11.582214 l 6.724392 
11.365671 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 6.074762 11.582235 m 6.074762 11.798778 l 6.724392 11.798778 l 6.724392 
11.582235 l cp s
+n 6.074762 11.582214 m 6.074762 11.798758 l 6.724392 11.798758 l 6.724392 
11.582214 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 6.074762 11.842086 m 6.074762 11.972012 l 6.480781 11.972012 l 6.480781 
11.842086 l cp s
+n 6.074762 11.842066 m 6.074762 11.971992 l 6.480781 11.971992 l 6.480781 
11.842066 l cp s
 0 slc
 0 slj
 [] 0 sd
 0.000000 1.000000 0.000000 srgb
-n 6.683790 11.863741 0.028421 0.028421 0 360 ellipse f
+n 6.683790 11.863721 0.028421 0.028421 0 360 ellipse f
 0.000000 0.000000 0.000000 srgb
-n 6.683790 11.863741 0.028421 0.028421 0 360 ellipse cp s
+n 6.683790 11.863721 0.028421 0.028421 0 360 ellipse cp s
 0 slc
 0 slj
 [] 0 sd
 1.000000 1.000000 0.000000 srgb
-n 6.683790 11.950358 0.028421 0.028421 0 360 ellipse f
+n 6.683790 11.950338 0.028421 0.028421 0 360 ellipse f
 0.000000 0.000000 0.000000 srgb
-n 6.683790 11.950358 0.028421 0.028421 0 360 ellipse cp s
+n 6.683790 11.950338 0.028421 0.028421 0 360 ellipse cp s
 0 slc
 0 slj
 [] 0 sd
 1.000000 1.000000 1.000000 srgb
-n 6.521383 11.885395 m 6.521383 11.972012 l 6.618827 11.972012 l 6.618827 
11.885395 l f
+n 6.521383 11.885375 m 6.521383 11.971992 l 6.618827 11.971992 l 6.618827 
11.885375 l f
 0.000000 0.000000 0.000000 srgb
-n 6.521383 11.885395 m 6.521383 11.972012 l 6.618827 11.972012 l 6.618827 
11.885395 l cp s
+n 6.521383 11.885375 m 6.521383 11.971992 l 6.618827 11.971992 l 6.618827 
11.885375 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 6.128898 12.145247 m 6.128898 12.618935 l s
+n 6.128898 12.145227 m 6.128898 12.618916 l s
 0 slc
 0 slj
 [] 0 sd
-n 6.264238 12.145247 m 6.264238 12.618935 l s
+n 6.264237 12.145227 m 6.264237 12.618916 l s
 0 slc
 0 slj
 [] 0 sd
-n 6.399577 12.145247 m 6.399577 12.618935 l s
+n 6.399577 12.145227 m 6.399577 12.618916 l s
 0 slc
 0 slj
 [] 0 sd
-n 6.534917 12.145247 m 6.534917 12.618935 l s
+n 6.534917 12.145227 m 6.534917 12.618916 l s
 0 slc
 0 slj
 [] 0 sd
-n 6.670256 12.145247 m 6.670256 12.618935 l s
+n 6.670256 12.145227 m 6.670256 12.618916 l s
 0 slc
 0 slj
 [] 0 sd
-n 6.805595 12.145247 m 6.805595 12.618935 l s
+n 6.805596 12.145227 m 6.805596 12.618916 l s
 0 slc
 0 slj
 [] 0 sd
 0.600000 0.600000 0.600000 srgb
-n 5.831151 12.876080 m 5.993559 12.551265 l 5.993559 12.713672 l 6.805595 
12.713672 l 6.805595 12.551265 l 7.022139 12.876080 l f
+n 5.831151 12.876061 m 5.993558 12.551246 l 5.993558 12.713654 l 6.805596 
12.713654 l 6.805596 12.551246 l 7.022139 12.876061 l f
 0.000000 0.000000 0.000000 srgb
-n 5.831151 12.876080 m 5.993559 12.551265 l 5.993559 12.713672 l 6.805595 
12.713672 l 6.805595 12.551265 l 7.022139 12.876080 l cp s
+n 5.831151 12.876061 m 5.993558 12.551246 l 5.993558 12.713654 l 6.805596 
12.713654 l 6.805596 12.551246 l 7.022139 12.876061 l cp s
 0.100000 slw
 [] 0 sd
 [] 0 sd
@@ -863,26 +863,26 @@
 0 slj
 [] 0 sd
 0.701961 0.701961 0.701961 srgb
-n 9.793559 1.868920 m 9.793559 3.763672 l 10.605595 3.763672 l 10.605595 
1.868920 l f
+n 9.793558 1.868919 m 9.793558 3.763674 l 10.605596 3.763674 l 10.605596 
1.868919 l f
 0.000000 0.000000 0.000000 srgb
-n 9.793559 1.868920 m 9.793559 3.763672 l 10.605595 3.763672 l 10.605595 
1.868920 l cp s
+n 9.793558 1.868919 m 9.793558 3.763674 l 10.605596 3.763674 l 10.605596 
1.868919 l cp s
 0.010000 slw
 0 slc
 0 slj
 [] 0 sd
-n 9.874762 1.982605 m 9.874762 2.199148 l 10.524392 2.199148 l 10.524392 
1.982605 l cp s
+n 9.874762 1.982604 m 9.874762 2.199148 l 10.524392 2.199148 l 10.524392 
1.982604 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 9.874762 2.199148 m 9.874762 2.415692 l 10.524392 2.415692 l 10.524392 
2.199148 l cp s
+n 9.874762 2.199148 m 9.874762 2.415691 l 10.524392 2.415691 l 10.524392 
2.199148 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 9.874762 2.415692 m 9.874762 2.632235 l 10.524392 2.632235 l 10.524392 
2.415692 l cp s
+n 9.874762 2.415691 m 9.874762 2.632234 l 10.524392 2.632234 l 10.524392 
2.415691 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 9.874762 2.632235 m 9.874762 2.848778 l 10.524392 2.848778 l 10.524392 
2.632235 l cp s
+n 9.874762 2.632234 m 9.874762 2.848778 l 10.524392 2.848778 l 10.524392 
2.632234 l cp s
 0 slc
 0 slj
 [] 0 sd
@@ -911,34 +911,34 @@
 0 slc
 0 slj
 [] 0 sd
-n 9.928898 3.195247 m 9.928898 3.668935 l s
+n 9.928898 3.195247 m 9.928898 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
-n 10.064238 3.195247 m 10.064238 3.668935 l s
+n 10.064237 3.195247 m 10.064237 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
-n 10.199577 3.195247 m 10.199577 3.668935 l s
+n 10.199577 3.195247 m 10.199577 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
-n 10.334917 3.195247 m 10.334917 3.668935 l s
+n 10.334917 3.195247 m 10.334917 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
-n 10.470256 3.195247 m 10.470256 3.668935 l s
+n 10.470256 3.195247 m 10.470256 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
-n 10.605595 3.195247 m 10.605595 3.668935 l s
+n 10.605596 3.195247 m 10.605596 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
 0.600000 0.600000 0.600000 srgb
-n 9.631151 3.926080 m 9.793559 3.601265 l 9.793559 3.763672 l 10.605595 
3.763672 l 10.605595 3.601265 l 10.822139 3.926080 l f
+n 9.631151 3.926081 m 9.793558 3.601266 l 9.793558 3.763674 l 10.605596 
3.763674 l 10.605596 3.601266 l 10.822139 3.926081 l f
 0.000000 0.000000 0.000000 srgb
-n 9.631151 3.926080 m 9.793559 3.601265 l 9.793559 3.763672 l 10.605595 
3.763672 l 10.605595 3.601265 l 10.822139 3.926080 l cp s
+n 9.631151 3.926081 m 9.793558 3.601266 l 9.793558 3.763674 l 10.605596 
3.763674 l 10.605596 3.601266 l 10.822139 3.926081 l cp s
 0.100000 slw
 [] 0 sd
 [] 0 sd
@@ -949,82 +949,82 @@
 0 slj
 [] 0 sd
 0.701961 0.701961 0.701961 srgb
-n 9.693559 10.868920 m 9.693559 12.763672 l 10.505595 12.763672 l 10.505595 
10.868920 l f
+n 9.693558 10.868899 m 9.693558 12.763654 l 10.505596 12.763654 l 10.505596 
10.868899 l f
 0.000000 0.000000 0.000000 srgb
-n 9.693559 10.868920 m 9.693559 12.763672 l 10.505595 12.763672 l 10.505595 
10.868920 l cp s
+n 9.693558 10.868899 m 9.693558 12.763654 l 10.505596 12.763654 l 10.505596 
10.868899 l cp s
 0.010000 slw
 0 slc
 0 slj
 [] 0 sd
-n 9.774762 10.982605 m 9.774762 11.199148 l 10.424392 11.199148 l 10.424392 
10.982605 l cp s
+n 9.774762 10.982584 m 9.774762 11.199128 l 10.424392 11.199128 l 10.424392 
10.982584 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 9.774762 11.199148 m 9.774762 11.415692 l 10.424392 11.415692 l 10.424392 
11.199148 l cp s
+n 9.774762 11.199128 m 9.774762 11.415671 l 10.424392 11.415671 l 10.424392 
11.199128 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 9.774762 11.415692 m 9.774762 11.632235 l 10.424392 11.632235 l 10.424392 
11.415692 l cp s
+n 9.774762 11.415671 m 9.774762 11.632214 l 10.424392 11.632214 l 10.424392 
11.415671 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 9.774762 11.632235 m 9.774762 11.848778 l 10.424392 11.848778 l 10.424392 
11.632235 l cp s
+n 9.774762 11.632214 m 9.774762 11.848758 l 10.424392 11.848758 l 10.424392 
11.632214 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 9.774762 11.892086 m 9.774762 12.022012 l 10.180781 12.022012 l 10.180781 
11.892086 l cp s
+n 9.774762 11.892066 m 9.774762 12.021992 l 10.180781 12.021992 l 10.180781 
11.892066 l cp s
 0 slc
 0 slj
 [] 0 sd
 0.000000 1.000000 0.000000 srgb
-n 10.383790 11.913741 0.028421 0.028421 0 360 ellipse f
+n 10.383790 11.913721 0.028421 0.028421 0 360 ellipse f
 0.000000 0.000000 0.000000 srgb
-n 10.383790 11.913741 0.028421 0.028421 0 360 ellipse cp s
+n 10.383790 11.913721 0.028421 0.028421 0 360 ellipse cp s
 0 slc
 0 slj
 [] 0 sd
 1.000000 1.000000 0.000000 srgb
-n 10.383790 12.000358 0.028421 0.028421 0 360 ellipse f
+n 10.383790 12.000338 0.028421 0.028421 0 360 ellipse f
 0.000000 0.000000 0.000000 srgb
-n 10.383790 12.000358 0.028421 0.028421 0 360 ellipse cp s
+n 10.383790 12.000338 0.028421 0.028421 0 360 ellipse cp s
 0 slc
 0 slj
 [] 0 sd
 1.000000 1.000000 1.000000 srgb
-n 10.221383 11.935395 m 10.221383 12.022012 l 10.318827 12.022012 l 10.318827 
11.935395 l f
+n 10.221383 11.935375 m 10.221383 12.021992 l 10.318827 12.021992 l 10.318827 
11.935375 l f
 0.000000 0.000000 0.000000 srgb
-n 10.221383 11.935395 m 10.221383 12.022012 l 10.318827 12.022012 l 10.318827 
11.935395 l cp s
+n 10.221383 11.935375 m 10.221383 12.021992 l 10.318827 12.021992 l 10.318827 
11.935375 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 9.828898 12.195247 m 9.828898 12.668935 l s
+n 9.828898 12.195227 m 9.828898 12.668916 l s
 0 slc
 0 slj
 [] 0 sd
-n 9.964238 12.195247 m 9.964238 12.668935 l s
+n 9.964237 12.195227 m 9.964237 12.668916 l s
 0 slc
 0 slj
 [] 0 sd
-n 10.099577 12.195247 m 10.099577 12.668935 l s
+n 10.099577 12.195227 m 10.099577 12.668916 l s
 0 slc
 0 slj
 [] 0 sd
-n 10.234917 12.195247 m 10.234917 12.668935 l s
+n 10.234917 12.195227 m 10.234917 12.668916 l s
 0 slc
 0 slj
 [] 0 sd
-n 10.370256 12.195247 m 10.370256 12.668935 l s
+n 10.370256 12.195227 m 10.370256 12.668916 l s
 0 slc
 0 slj
 [] 0 sd
-n 10.505595 12.195247 m 10.505595 12.668935 l s
+n 10.505596 12.195227 m 10.505596 12.668916 l s
 0 slc
 0 slj
 [] 0 sd
 0.600000 0.600000 0.600000 srgb
-n 9.531151 12.926080 m 9.693559 12.601265 l 9.693559 12.763672 l 10.505595 
12.763672 l 10.505595 12.601265 l 10.722139 12.926080 l f
+n 9.531151 12.926061 m 9.693558 12.601246 l 9.693558 12.763654 l 10.505596 
12.763654 l 10.505596 12.601246 l 10.722139 12.926061 l f
 0.000000 0.000000 0.000000 srgb
-n 9.531151 12.926080 m 9.693559 12.601265 l 9.693559 12.763672 l 10.505595 
12.763672 l 10.505595 12.601265 l 10.722139 12.926080 l cp s
+n 9.531151 12.926061 m 9.693558 12.601246 l 9.693558 12.763654 l 10.505596 
12.763654 l 10.505596 12.601246 l 10.722139 12.926061 l cp s
 0.100000 slw
 [] 0 sd
 [] 0 sd
@@ -1035,26 +1035,26 @@
 0 slj
 [] 0 sd
 0.701961 0.701961 0.701961 srgb
-n 6.093559 1.868920 m 6.093559 3.763672 l 6.905595 3.763672 l 6.905595 
1.868920 l f
+n 6.093558 1.868919 m 6.093558 3.763674 l 6.905596 3.763674 l 6.905596 
1.868919 l f
 0.000000 0.000000 0.000000 srgb
-n 6.093559 1.868920 m 6.093559 3.763672 l 6.905595 3.763672 l 6.905595 
1.868920 l cp s
+n 6.093558 1.868919 m 6.093558 3.763674 l 6.905596 3.763674 l 6.905596 
1.868919 l cp s
 0.010000 slw
 0 slc
 0 slj
 [] 0 sd
-n 6.174762 1.982605 m 6.174762 2.199148 l 6.824392 2.199148 l 6.824392 
1.982605 l cp s
+n 6.174762 1.982604 m 6.174762 2.199148 l 6.824392 2.199148 l 6.824392 
1.982604 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 6.174762 2.199148 m 6.174762 2.415692 l 6.824392 2.415692 l 6.824392 
2.199148 l cp s
+n 6.174762 2.199148 m 6.174762 2.415691 l 6.824392 2.415691 l 6.824392 
2.199148 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 6.174762 2.415692 m 6.174762 2.632235 l 6.824392 2.632235 l 6.824392 
2.415692 l cp s
+n 6.174762 2.415691 m 6.174762 2.632234 l 6.824392 2.632234 l 6.824392 
2.415691 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 6.174762 2.632235 m 6.174762 2.848778 l 6.824392 2.848778 l 6.824392 
2.632235 l cp s
+n 6.174762 2.632234 m 6.174762 2.848778 l 6.824392 2.848778 l 6.824392 
2.632234 l cp s
 0 slc
 0 slj
 [] 0 sd
@@ -1083,34 +1083,34 @@
 0 slc
 0 slj
 [] 0 sd
-n 6.228898 3.195247 m 6.228898 3.668935 l s
+n 6.228898 3.195247 m 6.228898 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
-n 6.364238 3.195247 m 6.364238 3.668935 l s
+n 6.364237 3.195247 m 6.364237 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
-n 6.499577 3.195247 m 6.499577 3.668935 l s
+n 6.499577 3.195247 m 6.499577 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
-n 6.634917 3.195247 m 6.634917 3.668935 l s
+n 6.634917 3.195247 m 6.634917 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
-n 6.770256 3.195247 m 6.770256 3.668935 l s
+n 6.770256 3.195247 m 6.770256 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
-n 6.905595 3.195247 m 6.905595 3.668935 l s
+n 6.905596 3.195247 m 6.905596 3.668936 l s
 0 slc
 0 slj
 [] 0 sd
 0.600000 0.600000 0.600000 srgb
-n 5.931151 3.926080 m 6.093559 3.601265 l 6.093559 3.763672 l 6.905595 
3.763672 l 6.905595 3.601265 l 7.122139 3.926080 l f
+n 5.931151 3.926081 m 6.093558 3.601266 l 6.093558 3.763674 l 6.905596 
3.763674 l 6.905596 3.601266 l 7.122139 3.926081 l f
 0.000000 0.000000 0.000000 srgb
-n 5.931151 3.926080 m 6.093559 3.601265 l 6.093559 3.763672 l 6.905595 
3.763672 l 6.905595 3.601265 l 7.122139 3.926080 l cp s
+n 5.931151 3.926081 m 6.093558 3.601266 l 6.093558 3.763674 l 6.905596 
3.763674 l 6.905596 3.601266 l 7.122139 3.926081 l cp s
 0.100000 slw
 [] 0 sd
 [] 0 sd
@@ -1121,82 +1121,82 @@
 0 slj
 [] 0 sd
 0.701961 0.701961 0.701961 srgb
-n 22.443559 10.868920 m 22.443559 12.763672 l 23.255595 12.763672 l 23.255595 
10.868920 l f
+n 22.443608 10.868899 m 22.443608 12.763654 l 23.255646 12.763654 l 23.255646 
10.868899 l f
 0.000000 0.000000 0.000000 srgb
-n 22.443559 10.868920 m 22.443559 12.763672 l 23.255595 12.763672 l 23.255595 
10.868920 l cp s
+n 22.443608 10.868899 m 22.443608 12.763654 l 23.255646 12.763654 l 23.255646 
10.868899 l cp s
 0.010000 slw
 0 slc
 0 slj
 [] 0 sd
-n 22.524762 10.982605 m 22.524762 11.199148 l 23.174392 11.199148 l 23.174392 
10.982605 l cp s
+n 22.524812 10.982584 m 22.524812 11.199128 l 23.174442 11.199128 l 23.174442 
10.982584 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 22.524762 11.199148 m 22.524762 11.415692 l 23.174392 11.415692 l 23.174392 
11.199148 l cp s
+n 22.524812 11.199128 m 22.524812 11.415671 l 23.174442 11.415671 l 23.174442 
11.199128 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 22.524762 11.415692 m 22.524762 11.632235 l 23.174392 11.632235 l 23.174392 
11.415692 l cp s
+n 22.524812 11.415671 m 22.524812 11.632214 l 23.174442 11.632214 l 23.174442 
11.415671 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 22.524762 11.632235 m 22.524762 11.848778 l 23.174392 11.848778 l 23.174392 
11.632235 l cp s
+n 22.524812 11.632214 m 22.524812 11.848758 l 23.174442 11.848758 l 23.174442 
11.632214 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 22.524762 11.892086 m 22.524762 12.022012 l 22.930781 12.022012 l 22.930781 
11.892086 l cp s
+n 22.524812 11.892066 m 22.524812 12.021992 l 22.930831 12.021992 l 22.930831 
11.892066 l cp s
 0 slc
 0 slj
 [] 0 sd
 0.000000 1.000000 0.000000 srgb
-n 23.133790 11.913741 0.028421 0.028421 0 360 ellipse f
+n 23.133840 11.913721 0.028421 0.028421 0 360 ellipse f
 0.000000 0.000000 0.000000 srgb
-n 23.133790 11.913741 0.028421 0.028421 0 360 ellipse cp s
+n 23.133840 11.913721 0.028421 0.028421 0 360 ellipse cp s
 0 slc
 0 slj
 [] 0 sd
 1.000000 1.000000 0.000000 srgb
-n 23.133790 12.000358 0.028421 0.028421 0 360 ellipse f
+n 23.133840 12.000338 0.028421 0.028421 0 360 ellipse f
 0.000000 0.000000 0.000000 srgb
-n 23.133790 12.000358 0.028421 0.028421 0 360 ellipse cp s
+n 23.133840 12.000338 0.028421 0.028421 0 360 ellipse cp s
 0 slc
 0 slj
 [] 0 sd
 1.000000 1.000000 1.000000 srgb
-n 22.971383 11.935395 m 22.971383 12.022012 l 23.068827 12.022012 l 23.068827 
11.935395 l f
+n 22.971433 11.935375 m 22.971433 12.021992 l 23.068877 12.021992 l 23.068877 
11.935375 l f
 0.000000 0.000000 0.000000 srgb
-n 22.971383 11.935395 m 22.971383 12.022012 l 23.068827 12.022012 l 23.068827 
11.935395 l cp s
+n 22.971433 11.935375 m 22.971433 12.021992 l 23.068877 12.021992 l 23.068877 
11.935375 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 22.578898 12.195247 m 22.578898 12.668935 l s
+n 22.578948 12.195227 m 22.578948 12.668916 l s
 0 slc
 0 slj
 [] 0 sd
-n 22.714238 12.195247 m 22.714238 12.668935 l s
+n 22.714287 12.195227 m 22.714287 12.668916 l s
 0 slc
 0 slj
 [] 0 sd
-n 22.849577 12.195247 m 22.849577 12.668935 l s
+n 22.849627 12.195227 m 22.849627 12.668916 l s
 0 slc
 0 slj
 [] 0 sd
-n 22.984917 12.195247 m 22.984917 12.668935 l s
+n 22.984967 12.195227 m 22.984967 12.668916 l s
 0 slc
 0 slj
 [] 0 sd
-n 23.120256 12.195247 m 23.120256 12.668935 l s
+n 23.120306 12.195227 m 23.120306 12.668916 l s
 0 slc
 0 slj
 [] 0 sd
-n 23.255595 12.195247 m 23.255595 12.668935 l s
+n 23.255646 12.195227 m 23.255646 12.668916 l s
 0 slc
 0 slj
 [] 0 sd
 0.600000 0.600000 0.600000 srgb
-n 22.281151 12.926080 m 22.443559 12.601265 l 22.443559 12.763672 l 23.255595 
12.763672 l 23.255595 12.601265 l 23.472139 12.926080 l f
+n 22.281201 12.926061 m 22.443608 12.601246 l 22.443608 12.763654 l 23.255646 
12.763654 l 23.255646 12.601246 l 23.472189 12.926061 l f
 0.000000 0.000000 0.000000 srgb
-n 22.281151 12.926080 m 22.443559 12.601265 l 22.443559 12.763672 l 23.255595 
12.763672 l 23.255595 12.601265 l 23.472139 12.926080 l cp s
+n 22.281201 12.926061 m 22.443608 12.601246 l 22.443608 12.763654 l 23.255646 
12.763654 l 23.255646 12.601246 l 23.472189 12.926061 l cp s
 0.100000 slw
 [] 0 sd
 [] 0 sd
@@ -1207,82 +1207,82 @@
 0 slj
 [] 0 sd
 0.701961 0.701961 0.701961 srgb
-n 18.943559 5.918920 m 18.943559 7.813672 l 19.755595 7.813672 l 19.755595 
5.918920 l f
+n 18.943608 5.918919 m 18.943608 7.813674 l 19.755646 7.813674 l 19.755646 
5.918919 l f
 0.000000 0.000000 0.000000 srgb
-n 18.943559 5.918920 m 18.943559 7.813672 l 19.755595 7.813672 l 19.755595 
5.918920 l cp s
+n 18.943608 5.918919 m 18.943608 7.813674 l 19.755646 7.813674 l 19.755646 
5.918919 l cp s
 0.010000 slw
 0 slc
 0 slj
 [] 0 sd
-n 19.024762 6.032605 m 19.024762 6.249148 l 19.674392 6.249148 l 19.674392 
6.032605 l cp s
+n 19.024812 6.032604 m 19.024812 6.249148 l 19.674442 6.249148 l 19.674442 
6.032604 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 19.024762 6.249148 m 19.024762 6.465692 l 19.674392 6.465692 l 19.674392 
6.249148 l cp s
+n 19.024812 6.249148 m 19.024812 6.465691 l 19.674442 6.465691 l 19.674442 
6.249148 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 19.024762 6.465692 m 19.024762 6.682235 l 19.674392 6.682235 l 19.674392 
6.465692 l cp s
+n 19.024812 6.465691 m 19.024812 6.682234 l 19.674442 6.682234 l 19.674442 
6.465691 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 19.024762 6.682235 m 19.024762 6.898778 l 19.674392 6.898778 l 19.674392 
6.682235 l cp s
+n 19.024812 6.682234 m 19.024812 6.898778 l 19.674442 6.898778 l 19.674442 
6.682234 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 19.024762 6.942086 m 19.024762 7.072012 l 19.430781 7.072012 l 19.430781 
6.942086 l cp s
+n 19.024812 6.942086 m 19.024812 7.072012 l 19.430831 7.072012 l 19.430831 
6.942086 l cp s
 0 slc
 0 slj
 [] 0 sd
 0.000000 1.000000 0.000000 srgb
-n 19.633790 6.963741 0.028421 0.028421 0 360 ellipse f
+n 19.633840 6.963741 0.028421 0.028421 0 360 ellipse f
 0.000000 0.000000 0.000000 srgb
-n 19.633790 6.963741 0.028421 0.028421 0 360 ellipse cp s
+n 19.633840 6.963741 0.028421 0.028421 0 360 ellipse cp s
 0 slc
 0 slj
 [] 0 sd
 1.000000 1.000000 0.000000 srgb
-n 19.633790 7.050358 0.028421 0.028421 0 360 ellipse f
+n 19.633840 7.050358 0.028421 0.028421 0 360 ellipse f
 0.000000 0.000000 0.000000 srgb
-n 19.633790 7.050358 0.028421 0.028421 0 360 ellipse cp s
+n 19.633840 7.050358 0.028421 0.028421 0 360 ellipse cp s
 0 slc
 0 slj
 [] 0 sd
 1.000000 1.000000 1.000000 srgb
-n 19.471383 6.985395 m 19.471383 7.072012 l 19.568827 7.072012 l 19.568827 
6.985395 l f
+n 19.471433 6.985395 m 19.471433 7.072012 l 19.568877 7.072012 l 19.568877 
6.985395 l f
 0.000000 0.000000 0.000000 srgb
-n 19.471383 6.985395 m 19.471383 7.072012 l 19.568827 7.072012 l 19.568827 
6.985395 l cp s
+n 19.471433 6.985395 m 19.471433 7.072012 l 19.568877 7.072012 l 19.568877 
6.985395 l cp s
 0 slc
 0 slj
 [] 0 sd
-n 19.078898 7.245247 m 19.078898 7.718935 l s
+n 19.078948 7.245247 m 19.078948 7.718936 l s
 0 slc
 0 slj
 [] 0 sd
-n 19.214238 7.245247 m 19.214238 7.718935 l s
+n 19.214287 7.245247 m 19.214287 7.718936 l s
 0 slc
 0 slj
 [] 0 sd
-n 19.349577 7.245247 m 19.349577 7.718935 l s
+n 19.349627 7.245247 m 19.349627 7.718936 l s
 0 slc
 0 slj
 [] 0 sd
-n 19.484917 7.245247 m 19.484917 7.718935 l s
+n 19.484967 7.245247 m 19.484967 7.718936 l s
 0 slc
 0 slj
 [] 0 sd
-n 19.620256 7.245247 m 19.620256 7.718935 l s
+n 19.620306 7.245247 m 19.620306 7.718936 l s
 0 slc
 0 slj
 [] 0 sd
-n 19.755595 7.245247 m 19.755595 7.718935 l s
+n 19.755646 7.245247 m 19.755646 7.718936 l s
 0 slc
 0 slj
 [] 0 sd
 0.600000 0.600000 0.600000 srgb
-n 18.781151 7.976080 m 18.943559 7.651265 l 18.943559 7.813672 l 19.755595 
7.813672 l 19.755595 7.651265 l 19.972139 7.976080 l f
+n 18.781201 7.976081 m 18.943608 7.651266 l 18.943608 7.813674 l 19.755646 
7.813674 l 19.755646 7.651266 l 19.972189 7.976081 l f
 0.000000 0.000000 0.000000 srgb
-n 18.781151 7.976080 m 18.943559 7.651265 l 18.943559 7.813672 l 19.755595 
7.813672 l 19.755595 7.651265 l 19.972139 7.976080 l cp s
+n 18.781201 7.976081 m 18.943608 7.651266 l 18.943608 7.813674 l 19.755646 
7.813674 l 19.755646 7.651266 l 19.972189 7.976081 l cp s
 0.100000 slw
 [] 0 sd
 [] 0 sd
@@ -1357,7 +1357,7 @@
 [] 0 sd
 [] 0 sd
 0 slc
-n 17.426600 5.012514 3.668194 3.668194 239.712753 300.287247 ellipse s
+n 17.426600 5.012512 3.668192 3.668192 239.712736 300.287264 ellipse s
 0.100000 slw
 [0.200000] 0 sd
 [0.200000] 0 sd
@@ -1411,7 +1411,7 @@
 0 slj
 0.000000 0.000000 0.000000 srgb
 n 16.223553 8.021562 m 17.100000 8.200000 l 16.716882 7.391779 l cp s
-11.723061 11.044320 m  [ /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi /xi 
/xi /xi /xi
+11.723100 11.044300 m  [ /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
  /P /h /y /s /i /c /a /l /xi /xi /space /n /k /V /r /t
  /u /A /p /o /e /S /T /N /w /D /g /f /hyphen /xi /xi /xi
@@ -1439,25 +1439,25 @@
 /Helvetica_e0 ff 0.700000 scf sf
 ( !"#$%&')
  gs 1 -1 sc sh gr
-11.723061 11.744320 m (*'$+,)
+11.723100 11.744300 m (*'$+,)
  gs 1 -1 sc sh gr
 0.100000 slw
 [] 0 sd
 [] 0 sd
 0 slc
-n 13.323061 10.394320 m 15.589400 9.339360 l s
+n 13.323100 10.394300 m 15.589400 9.339360 l s
 0 slj
 1.000000 1.000000 1.000000 srgb
-n 15.032931 10.039604 m 15.589400 9.339360 l 14.695323 9.314332 l f
+n 15.032931 10.039604 m 15.589400 9.339360 l 14.695323 9.314331 l f
 0.100000 slw
 [] 0 sd
 0 slj
 0.000000 0.000000 0.000000 srgb
-n 15.032931 10.039604 m 15.589400 9.339360 l 14.695323 9.314332 l cp s
-12.673061 5.494310 m /Helvetica_e0 ff 0.700000 scf sf
+n 15.032931 10.039604 m 15.589400 9.339360 l 14.695323 9.314331 l cp s
+12.673100 5.494310 m /Helvetica_e0 ff 0.700000 scf sf
 (-$./0&')
  gs 1 -1 sc sh gr
-12.673061 6.194310 m (*'$+,)
+12.673100 6.194310 m (*'$+,)
  gs 1 -1 sc sh gr
 /Helvetica_e0 ff 0.700000 scf sf
 (122'$%&/$3+*) sw
@@ -1519,23 +1519,23 @@
 [] 0 sd
 0 slc
 0.000000 0.000000 0.000000 srgb
-n 12.223061 10.344320 m 10.373061 8.744310 l s
+n 12.223100 10.344300 m 10.373100 8.744310 l s
 0 slj
 1.000000 1.000000 1.000000 srgb
-n 11.239812 8.965089 m 10.373061 8.744310 l 10.716488 9.570178 l f
+n 11.239852 8.965084 m 10.373100 8.744310 l 10.716532 9.570176 l f
 0.100000 slw
 [] 0 sd
 0 slj
 0.000000 0.000000 0.000000 srgb
-n 11.239812 8.965089 m 10.373061 8.744310 l 10.716488 9.570178 l cp s
-16.062011 0.525611 m /Helvetica_e0 ff 0.700000 scf sf
-(6323'3:"*3;* 44.</3< 44.)
+n 11.239852 8.965084 m 10.373100 8.744310 l 10.716532 9.570176 l cp s
+16.062000 0.525611 m /Helvetica_e0 ff 0.700000 scf sf
+(6323'3:"*3;*&* 44.</3< 44.)
  gs 1 -1 sc sh gr
-16.062011 1.225611 m (+4/83.,)
+16.062000 1.225611 m (+4/83.,)
  gs 1 -1 sc sh gr
-4.073061 0.525611 m /Helvetica_e0 ff 0.700000 scf sf
-(6323'3:"*3;*.4:0'&.)
+4.073060 0.525611 m /Helvetica_e0 ff 0.700000 scf sf
+(6323'3:"*3;*&*.4:0'&.)
  gs 1 -1 sc sh gr
-4.073061 1.225611 m (+4/83.,)
+4.073060 1.225611 m (+4/83.,)
  gs 1 -1 sc sh gr
 showpage
Index: gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
diff -u gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.152 
gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.153
--- gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.152      Mon Mar 
17 06:42:01 2003
+++ gzz/Documentation/misc/hemppah-progradu/masterthesis.tex    Mon Mar 17 
10:07:39 2003
@@ -42,9 +42,8 @@
 \abstract{
 In this thesis, we review existing Peer-to-Peer approaches, algorithms and 
their
 key properties. We summarize open problems in Peer-to-Peer systems and divide
-problems into three sub-categories. We observe that there are many
-problems which have no solutions at all, or problems that have proposed
-solutions but which are practically unrealizable.
+problems into three sub-categories. We observe that there are many problems 
with 
+either no solutions at all, or only practically unrealizable ones.
 
 Then, we give an overview of the Fenfire system.  We evaluate existing
 Peer-to-Peer approaches-- loosely and tightly structured overlays-- with regard
@@ -84,7 +83,7 @@
 academia \cite{projectirisurl} and industry \cite{p2pworkinggroup, jxtaurl} 
for a 
 number of reasons. The lack of centralization in Peer-to-Peer systems
 means that the participants can form a distributed system without any 
investment to 
-centralized hardware which would coordinate it by sharing their services
+centralized hardware, which would coordinate it by sharing their services
 and connecting to each other directly. Additionally, the distributed and ad 
hoc nature of 
 Peer-to-Peer improves scalability and avoids single points of failure.
 
@@ -95,23 +94,22 @@
 capabilities and responsibilities. Each entity, i.e., \emph{peer}, may 
contribute services 
 to the overall system.
 
-The Fenfire project is an attempt to build hyperstructured, seamlessly 
interoperating desktop 
-environment. In Fenfire, all data is stored as data blocks.  
+The Fenfire project is an attempt to build a hyperstructured, seamlessly 
interoperating desktop 
+environment. In the Fenfire, all data is stored as data blocks.  
 All data blocks have globally unique identifiers and they can be referred by 
pointer blocks. 
-Other features of Fenfire include innovative user 
+Other features of the Fenfire include innovative user 
 interfaces for viewing data and usage of Peer-to-Peer networking for network 
transparency. 
 
-In this thesis, we\footnote{Use of the plural is customary even if research 
-paper is authored solely.} evaluate existing Peer-to-Peer approaches and
+In this thesis, we evaluate existing Peer-to-Peer approaches and
 choose the best alternative to Fenfire's needs. 
 
 We start by reviewing existing Peer-to-Peer approaches, algorithms and their 
key properties. 
-We observe that despite the great amount of proposed Peer-to-Peer systems, all 
systems fall either to
-loosely structured approach or tightly structured approach. We also discuss 
open problems in 
-Peer-to-Peer systems and divide problems into three sub-categories: security 
problems, 
-performance problems and miscellaneous problems.  
+We observe that despite the great amount of proposed Peer-to-Peer systems, all 
systems fall either to loosely or 
+tightly structured approach. We also discuss open problems in 
+Peer-to-Peer systems and divide problems into three sub-categories: security, 
performance, and miscellaneous 
+problems.  
 
-Then, we give an overview of Fenfire project, and evaluate Peer-to-Peer 
approaches to Fenfire's 
+Then, we give an overview of the Fenfire project, and evaluate Peer-to-Peer 
approaches to Fenfire's 
 needs. Finally, we propose simple but yet efficient methods to be used for 
data lookups in Peer-to-Peer 
 environment. 
 
@@ -120,7 +118,7 @@
 information can be found from the references.
 
 There are three research problems discussed in this thesis. First research 
problem
-is to find the most efficient way to locate and fetch Fenfire data blocks from 
a 
+is finding the most efficient way to locate and fetch Fenfire data blocks from 
a 
 Peer-to-Peer network, where the block's identifier is given. Second, we want
 to find the most efficient way to locate and fetch the most recent Fenfire 
data block from a
 Peer-to-Peer network referred by a pointer block. The third problem
@@ -130,44 +128,44 @@
 This thesis is structured as follows. In the next chapter, we give an overview 
of
 existing Peer-to-Peer approaches, algorithms and key differences between them. 
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. 
+sub-categories. Chapter 4 gives an overview of the Fenfire system. In chapter
+5, we evaluate existing Peer-to-Peer approaches with regard to the Fenfire 
system. 
 Finally, in chapter 6 we conclusions and future work.
 
 
 \chapter{Peer-to-Peer architectures}
 In this chapter we will give a brief history and overview of Peer-to-Peer 
networks, 
-review most important Peer-to-Peer algorithms and list key differences between 
+review most the important Peer-to-Peer algorithms and list key differences 
between the 
 two main approaches.
 
 \section{Brief history and overview}
 
-The Internet has been originally established in the late 1960s. The objective 
+The Internet was originally established in the late 1960s. The objective 
 of the ARPANET-project was to share computers' resources among military 
computers
 around the United States. The most challenging purpose of ARPANET was to 
integrate 
 different kinds of existing network technologies with one common network 
architecture. 
 The ARPANET connected the first few hosts together not in client/server 
relationship, 
-but rather as equal networking \emph{peers}. This could be seen as starting 
point 
-both of Peer-to-Peer concept and the Internet \cite{oram01harnessingpower}. 
+but rather as equal networking \emph{peers}. This could be seen as the 
starting point 
+of both the Peer-to-Peer concept and the Internet 
\cite{oram01harnessingpower}. 
 
 In subsequent years, the Internet became more restricted to client--server 
based 
 applications. In recent years, however, Peer-to-Peer systems have again 
emerged 
-room in computing world. Indeed, Peer-to-Peer has had significant social and 
technical 
-attention in academia \cite{projectirisurl}, industry \cite{p2pworkinggroup}, 
-\cite{jxtaurl}. Already deceased Napster \cite{napsterurl}, 
+in computing world. Indeed, Peer-to-Peer has had significant social and 
technical 
+attention in academia \cite{projectirisurl} and industry 
\cite{p2pworkinggroup, jxtaurl}. 
+The deceased Napster \cite{napsterurl}, 
 launched in 1999, was a new starting point for modern Peer-to-Peer computing. 
After
 Napster, hundreds of Peer-to-Peer systems have been developed and proposed. 
 
-Modern Peer-to-Peer system is composed of \emph{application} level overlay 
network.
+A modern Peer-to-Peer system is composed of an \emph{application} level 
overlay network.
 Figure \ref{fig:application_level} illustrates the analogy of Peer-to-Peer 
network with
 regard to OSI model. Compared to ARPANET's Peer-to-Peer functionality, modern 
Peer-to-Peer systems
 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
+of the overlay network. Even more demanding tasks are performing efficient data
+lookup and maintaining security in a varying distributed environment. The most 
popular
 form of modern Peer-to-Peer computing is file-sharing. In this scenario, 
participants
-of Peer-to-Peer network share their file resources to other participants while 
obtaining
-more resources from others. This can be seen as a variant of distributed file 
system
+of Peer-to-Peer network share their file resources with other participants.
+ This can be seen as a variant of distributed file system
 (e.g., \cite{levy90distributedfilesystems}). 
 
 \begin{figure}
@@ -179,27 +177,25 @@
 
 
 
-In a development of modern Peer-to-Peer systems, lot of influences has been 
attained from 
+In the development of modern Peer-to-Peer systems, lot of influence has been 
attained from 
 other research areas than computer science. Research has been conducted 
regarding 
-to self-organizing nature of complex networks \cite{albert-02-statistical}, 
\cite{albert-00-tolerance}, \cite{watts00dynamics}. 
-It's interesting to realize that chemical properties of cells, the Internet, 
ad hoc 
-Peer-to-Peer systems, and social networks have all in common that they 
self-organize based on same 
+the self-organizing nature of complex networks \cite{albert-02-statistical, 
albert-00-tolerance, watts00dynamics}. 
+It is interesting to realize that chemical properties of biological cells, the 
Internet, ad hoc 
+Peer-to-Peer systems, and social networks have all in common that they 
self-organize based on the same 
 principles.  Furthermore, the association between social relationships among 
people 
-and Peer-to-Peer overlay topology has been studied recently  
\cite{watts00dynamics}, 
-\cite{kleinberg99small}, \cite{nips02-Kleinberg}. This insight is motivated
-by Milgram, who noticed that people are very effective to locate other people 
in a wide scale 
+and Peer-to-Peer overlay topology has been studied recently 
\cite{watts00dynamics, kleinberg99small, nips02-Kleinberg}. 
+This insight is motivated by Milgram, who noticed that people are very 
effective in locating other people in a wide scale 
 based on local knowledge. This phenomenon is called as ''small-world 
phenomenon'' 
 \cite{milgram67smallworld}. As a consequence, many modern Peer-to-Peer systems
 have applied techniques outside of computer science when constructing and 
maintaining
 the application level overlay network.
 
 In the end, however, there are two main approaches in which all modern 
Peer-to-Peer
-systems fall: loosely structured approach and tightly structured approach. In 
loosely
+systems fall: the loosely structured approach and the tightly structured 
approach. In the loosely
 structured approach the construction and the maintenance of the overlay is 
controlled 
 loosely. This approach gives freedom for participating peers
-to perform certain tasks in Peer-to-Peer network. On the other hand, tightly 
structured
-approach has some rules, which all participating peers have to obey. In the 
following
-sections, we will discuss in more detail both approaches and key differences 
between them. 
+to perform certain tasks in a Peer-to-Peer network. On the other hand, the 
tightly structured
+approach has some rules, which all participating peers have to obey.
 
 
 \section{Centralized}
@@ -208,8 +204,8 @@
 historical value (see previous section).} \cite{napsterurl}  was designed 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 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 were totally 
based on 
+Peers in the Napster network made requests to the central directory server to 
find 
+other peers hosting desirable content. Since service requests were totally 
based on a 
 centralized index, Napster didn't scale well because of constantly updated 
central 
 directory, and had a single point of failure. 
 
@@ -221,10 +217,10 @@
 The construction and maintenance of Gnutella network is extremely ad hoc, 
since participating
 peers can form the overlay network based on \emph{local} knowledge. Figure 
\ref{fig:gnutella_overlay}
 illustrates how peers form an overlay network. Initially, peer 1 creates the 
overlay, since
-it's the first participating peer. Then, repeatedly new peers join the network 
and connect to
+it is the first participating peer. Then, repeatedly new peers join the 
network and connect to
 other peers in a random manner. Thus, Gnutella can be considered as a 
variation of \emph{scale-free
 graph}\footnote{In scale-free graphs (also known as power-law graphs) only a 
few peers have high number of neighbor 
-links and major of peers have low number of neighbor links.}.
+links and the majority of peers have low number of neighbor links.}.
 
 \begin{figure}
 \centering
@@ -234,10 +230,10 @@
 \end{figure}
 
 
-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
+In Gnutella, each participating peer maintains a local index of its own shared 
content. Also,
+each peer has a few connections to other peers, i.e., peer's \emph{neighbors}. 
Basic Gnutella
 data lookup works as follows: peer broadcasts a query request to its 
neighbors, which in turn
-forwards the query to their neighbors. This leads to a situation where number 
of messages
+forward the query to their neighbors. This leads to a situation where the 
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 distribute queries. Therefore, Gnutella uses a 
Breadth-First-Search (BFS) algorithm
@@ -254,31 +250,29 @@
 \label{fig:gnutella_query}
 \end{figure}
 
-According to \cite{lv02searchreplication}, Gnutella's way to perform data 
lookups, \emph{flooding}, has
+According to \cite{lv02searchreplication}, Gnutella's way to perform data 
lookups, \emph{flooding}, has the
 following limitations. First, choosing the appropriate TTL in practice is not 
easy. If the
 TTL is too high, query originator may unnecessarily strain the network. If the 
TTL is too
-low, the query originator might not find the desired data even if it's 
available somewhere
+low, the query originator might not find the desired data even if it is 
available somewhere
 in the network. Second, there are many duplicate messages generated by 
flooding, especially
 in high connectivity graphs. It is obvious that with these limitations, 
flooding creates 
 significant message processing overhead for each data lookup. Even worse, 
flooding may increase 
-the load on participating to the point, where it has to leave the network. 
+the load on participating peer 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 al. \cite{adamic99small}, 
\cite{adamic02localsearch}, 
-\cite{adamic01powerlawsearch} have studied different data lookup methods in 
power-law 
-networks and have found that by 
-instructing peers forwarding data lookups to select high degree peers, the 
performance of data lookup 
+Lately, Gnutella's data lookup efficiency and scalability has been deeply 
researched.
+Adamic et al. \cite{adamic99small, adamic02localsearch, 
adamic01powerlawsearch} 
+have studied different data lookup methods in power-law networks and have 
found that by 
+instructing the peers that forward data lookups to select high degree peers, 
the performance of data lookup 
 increases significantly. As a result, some of the most recent loosely
 structured Peer-to-Peer systems have adopted this method with some 
modifications
-\cite{gnutella2url}, \cite{shareazaurl}, \cite{fasttrackurl}, 
\cite{morpheusurl}, 
-\cite{kazaaurl}, \cite{waterhouse02searchp2p}, \cite{botros01jxtasearch},
-\cite{ganesan02yappers}.
+\cite{gnutella2url, shareazaurl, fasttrackurl, morpheusurl, kazaaurl, 
waterhouse02searchp2p, botros01jxtasearch, 
+ganesan02yappers}.
 Figures \ref{fig:gnutella_overlay_supernodes} and 
\ref{fig:gnutella_overlay_cluster}
 illustrates simplified variations of power-law overlay networks. Figure 
\ref{fig:gnutella_powerlaw}
-presents pure topology of power-law network. 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 requests are sent only to the high degree peers, 
making 
+presents pure topology of power-law network. 
+
+It is not clear whether this algorithm is scalable or not, 
+as the majority of the query requests are sent only to the high degree peers, 
making 
 them stress the load of entire system.
 
 \begin{figure}
@@ -303,17 +297,17 @@
 \end{figure}    
 
 Previously presented improvements are only partial solutions. More advanced 
techniques 
-to improve data lookup of loosely structured systems are presented in chapter 
3.
+to improve data lookup of loosely structured systems are discussed in chapter 
3.
 
 
-\subsection{Sketch of formal definition}
+\subsection{Sketch of a formal definition}
 
 In this subsection we formalize loosely structured overlay's main components. 
This
 model is based on original Gnutella overlay network with power-law 
improvements.
 
 Let $S$ be the aggregate of all services $s$ in system. Let $P$ be the 
aggregate of 
 all peers $p$ in system. Then, $\forall s \in S$, there is a provider of the 
service, 
-expressed as $p = provider(s)$. Every $p$ has neighbor(s), named as 
$neighbor$, which 
+expressed as $p = provider(s)$. Every $p$ has neighbor(s), named as $p_n$, 
which 
 is $P$ = \{$p \in P: \exists neighbor$, which is randomly chosen from $P$\}.
 \emph{Super peer} is a peer, which hosts the indices of other peers, $si = 
summaryindex(provider(s))$
 and $\forall$ regular peer $p$, there is super peer, which has has a index of 
regular
@@ -332,7 +326,7 @@
 Skip Graphs \cite{AspnesS2003}, SkipNet \cite{harvey03skipnet2}, 
 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,
+The biggest difference compared to the 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 tighty structured 
systems, they all have in common
 that \emph{peer identifiers} are assigned to participating peers from
@@ -342,19 +336,19 @@
 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 circular identifier space of $n$-bit 
integers modulo $2^{n}$. The
+and Viceroy \cite{malkhi02viceroy} use a circular identifier space of $n$-bit 
integers modulo $2^{n}$. The
 value of $n$ varies among systems. Again, CAN \cite{ratnasamy01can} uses a 
$d$-dimensional Cartesian 
 model to implement identifier space.
 
-To store data into tightly structured overlay, each application-specific
+To store data into a tightly structured overlay, each application-specific
 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 an existing peer in the overlay. 
Thus, tightly 
-structured overlay assigns a subset of all possible keys to every 
participating peer 
-\footnote{We say that a peer is \emph{responsible} for the keys which are 
assigned by the overlay.}.  
+structured overlay assigns a subset of all possible keys to every 
participating peer. 
+We say that a peer is \emph{responsible} for the keys which are assigned by 
the overlay.  
 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 structured overlays.
+consists of identifiers and IP addresses of other peers in the overlay. 
Entries of the routing
+table represents peer's neighbors in the overlay network. Figure 
\ref{fig:structured_hashing} illustrates the 
+process of data to key mapping in a tightly structured overlay.
 
 \begin{figure}
 \centering
@@ -367,30 +361,27 @@
 peer identifier is gradually ''closer'' to the key's identifier
 in the identifier space. The distance can be measured by numerical
 difference between identifiers (e.g., Chord \cite{stoica01chord}), number of
-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
+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}).
+Chord's \cite{stoica01chord} distance function does have the property of 
unidirection
 (for a given point $p_i$ in the identifier space and distance $d$ > 0, there
 is exactly one point $p_j$ in a way that the distance between $p_i$ and $p_j$
-is $d$) and symmetric (the distance from $p_i$ to $p_j$ is same as the
-distance from $p_j$ to $p_i$) \cite{maymounkov02kademlia}. On the other
-hand, Chord's \cite{stoica01chord} distance function does have the property 
-of unidirection, but doesn't have symmetry. Pastry's \cite{rowston01pastry} 
distance 
-function supports symmetry, but doesn't support unidirection. As a 
consequence, 
-Kademlia's \cite{maymounkov02kademlia} XOR-based metric doesn't need 
-stabilization (like in Chord \cite{stoica01chord}) and backup links 
+is $d$), but doesn't have symmetry (the distance from $p_i$ to $p_j$ is same 
as the
+distance from $p_j$ to $p_i$). Pastry's \cite{rowston01pastry} distance 
function supports 
+symmetry, but doesn't support unidirection. Because of XOR-metric, Kademlia's 
distance 
+function is both unidirectional and symmetric. Moreover, Kademlia's 
\cite{maymounkov02kademlia} 
+XOR-based metric doesn't need 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 the 
data lookup 
-and the key which was looked up in the identifier space. 
+However, in all previous schemes each 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 \cite{AspnesS2003} and SWAN \cite{bonsma02swan} employ a key space 
very similar to a tightly structured
 overlay, but in which queries are routed  to \emph{keys}. In these systems
-peer occupies several positions in the identifier space, one for each 
+a 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 is responsible for the
-assigned keys.} is removed at the cost of each peer maintaining one 
-''resource peer'' in the overlay network for each data item it publishes.
+custody of a storing peer is removed at the cost of each peer maintaining one 
+''resource peer'' in the overlay network for each data item it publishes. 
Provider peer is the peer 
+in the overlay which is responsible for the assigned keys
 
 PeerNet \cite{eriksson03peernet} differs from other tightly structured 
overlays in that it operates
 at the \emph{network} layer. PeerNet makes an explicit distinction 
@@ -400,13 +391,12 @@
 for maintaining information about other peers in the system and 
 $O(\log{n})$ data lookup efficiency.
 
-Balakrishnan et al. \cite{balakrishanarticle03lookupp2p} have listed 
-four requirements for tightly structured overlays, which have to be 
+Balakrishnan et al. \cite{balakrishanarticle03lookupp2p} which have to be 
 addressed in order to perform efficient data lookups in tightly structured 
overlays. 
 First, mapping of keys to peers must be done in a load-balanced
 way. Second, the overlay must be able to forward a lookup for a 
-specific key to an appropriate peer. Third, overlay must have a
-support for a distance function. Finally,  routing tables for each peer
+specific key to an appropriate peer. Third, overlay must have
+support for a efficient distance function. Finally,  routing tables for each 
peer
 must be constructed and maintained adaptively.
 
 Currently, all proposed tightly structured overlays provide at least 
@@ -417,14 +407,14 @@
 In figure \ref{fig:structured_query}, we present an overview of Chord's lookup 
process.
 On the right side of Chord's lookup process, the same data lookup process
 is shown as a binary-tree abstraction.  It can be noticed, that in each step, 
the distance 
-decreases between with a logarithmic efficiency. 
+decreases with a logarithmic efficiency. 
 
 Kademlia \cite{maymounkov02kademlia}, Pastry \cite{rowston01pastry} and 
Tapestry 
 \cite{zhao01tapestry} uses balanced $k$-trees as routing table's data 
structure. Figure 
 \ref{fig:kademlia_lookup} shows the process of Kademlia's
 data lookup. Viceroy \cite{malkhi02viceroy} maintains a butterfly data 
structure (e.g., \cite{226658}), 
-which requires only constant number of neighbor peers while providing 
$O(\log{n})$ data lookup
-efficiency. Koorde \cite{kaashoek03koorde}, recent modification of Chord, uses 
de Bruijn graphs 
+which requires only a constant number of neighbor peers while providing 
$O(\log{n})$ data lookup
+efficiency. Koorde \cite{kaashoek03koorde}, a recent modification of Chord, 
uses de Bruijn graphs 
 \cite{debruijn46graph} to maintain local routing tables. Koorde 
\cite{kaashoek03koorde} requires 
 each peer to have only about two links to other peers to provide $O(\log{n})$ 
performance.
 
@@ -452,11 +442,10 @@
 \texttt{insert(key)}. As the name suggests, DHT implements the same 
functionality 
 as a regular hash table, by storing the mapping between a key and a value. 
DHT's 
 \emph{interface} is generic; values can be any size and type. Figure 
\ref{fig:Structured_lookup_using_DHT_model}
-shows the DHT abstraction of tightly structured overlay. Second, Decentralized 
-Object Location (DOLR) (see e.g., \cite{kubiatowicz00oceanstore}, 
\cite{iyer02squirrel}) is distributed 
-directory service. DOLR stores \emph{pointers} to where data items are stored 
-throughout the overlay. DOLR's main operations are \texttt{publish(key)}, 
-\texttt{removePublished(key)} and \texttt{sendToObject(key)}. The key 
+shows the DHT abstraction of the tightly structured overlay. Second, 
Decentralized 
+Object Location (DOLR) (see e.g., \cite{kubiatowicz00oceanstore}, 
\cite{iyer02squirrel}) is a distributed 
+directory service. DOLR stores \emph{pointers} to data items throughout the 
overlay. DOLR's main 
+operations are \texttt{publish(key)}, \texttt{removePublished(key)} and 
\texttt{sendToObject(key)}. The key 
 difference between DHT and DOLR abstraction is that DOLR routes overlay's 
messages
 to nearest available peer, hosting a specific data item. This form of locality
 is not supported by DHT. Finally, tightly structured overlay can be used for
@@ -485,12 +474,12 @@
 \end{figure}
 
 
-\subsection{Sketch of formal definition}
+\subsection{Sketch of a formal definition}
 
-In this subsection we formalize tightly structured overlay's main features, 
i.e., 
+In this subsection, we formalize the main 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 
+Let $S$ be the aggregate of all services $s$ in the system. Let $P$ be the 
aggregate of 
 all peers $p$ in system. Let $I$ be the aggregate of all identifiers $i$ in 
system. 
 Let $IS$ be the aggregate of all identifier points $ip$ in system. Then, 
$\forall s \in S$, 
 there is a provider of the service, expressed as $p = provider(s)$. Service's 
identifier 
@@ -506,35 +495,35 @@
 
 \section{Summary}
 
-In this section we compare loosely structured approach and tightly structured 
approach.
+In this section we compare the loosely structured approach and the tightly 
structured approach.
 We also summarize proposed Peer-to-Peer algorithms and their key properties 
with regard
 to performance and scalability aspects. 
 
 \subsection{Differences}
 
-Even though loosely structured and tightly structured approach are both 
Peer-to-Peer schemes, they 
+Even though the loosely structured and the tightly structured approach are 
both Peer-to-Peer schemes, they 
 have very little in common. Indeed, the only thing they share is the fact that 
no other peer is more
-important than an other in the Peer-to-Peer network. Fault tolerance \emph{may}
+important than any other in the Peer-to-Peer network. Fault tolerance 
\emph{may}
 be an area, in which approaches have similar properties (e.g., no single point 
of failure).
 Fault tolerance properties of both approaches are currently only initial 
calculations, or 
-experimented in simulation environments. In real-life, however, measuring 
fault tolerance is much more 
+experimented in simulation environments. In real-life, however, measuring 
fault tolerance is a much more 
 challenging task and requires more research to get reliable answers.
  
-The most important difference between approaches is performance and 
scalability properties. While 
-performance of loosely structured approach is not always even linear, 
generally tightly structured 
-approach can perform all internal operations in poly-logarithmic 
time\footnote{However, it is unknown 
-whether all proposed algorithms can preserve logarithmic properties in 
real-life applications or not.}.
+The most important difference between approaches is performance and 
scalability properties. Generally 
+tightly structured systems can perform all internal operations in 
poly-logarithmic time\footnote{However, it is unknown 
+whether all proposed algorithms can preserve logarithmic properties in 
real-life applications or not.}
+while the performance of loosely structured systems is not always even linear, 
.
 Moreover, loosely structured systems scale to millions of peers, whereas 
tightly structured systems are able
 to cope with billions of concurrent peers \cite{osokine02distnetworks}, 
\cite{kubiatowicz00oceanstore}.
 
 To end user, biggest difference between these systems is how data lookups are 
performed. Loosely
-structured systems provide more richer and user friendly way of searching data 
as they
-have support for keyword search. On the other hand, tightly structured systems 
support
-only exact key lookups as each data item is identified by globally unique keys.
+structured systems provide a more rich and user friendly way of searching data 
as they
+have support for keyword search than tightly structured systems. On the other 
hand, tightly structured 
+systems support only exact key lookups as each data item is identified by 
globally unique keys.
 
 In the end, both systems have open problems and issues. We will discuss these 
aspects in more detail in 
-chapter 3. Table \ref{table_comparison_approach} lists the key differences 
between loosely structured 
-approach and tightly structured approach.
+chapter 3. Table \ref{table_comparison_approach} lists the key differences 
between the loosely structured 
+approach and the tightly structured approach.
 
 
 \scriptsize
@@ -625,15 +614,13 @@
 
 Table \ref{table_Peer-to-Peer_algorithms} lists proposed Peer-to-Peer 
algorithms 
 and their key properties with regard to performance and scalability. List 
-includes algorithms from both loosely and tightly structured 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 
+includes algorithms from both loosely and tightly structured approaches. The 
list doesn't 
 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 be promising in the 
future 
 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
+We decided to follow the guidelines from \cite{kaashoek03koorde} in measuring
+the 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, however, we decided to include
 the number of \emph{real} network connections for each peer in the overlay. 
@@ -641,10 +628,10 @@
 Here, we describe the listed properties of Peer-to-Peer algorithms:
 
 \begin{itemize}
-\item \textbf{Lookup}: number of messages required when a data lookup is 
performed
-\item \textbf{Space}: number of neighbors which peers knows about (neighbors) 
-\item \textbf{Insert/delete}: number of messages required when a peer joins or 
leaves the network
- \item \textbf{Number of network connections}: number of concurrent network 
connections required to maintain correct neighbor information
+\item \textbf{Lookup}: the number of messages required when a data lookup is 
performed
+\item \textbf{Space}: the number of neighbors which peers knows about 
(neighbors) 
+\item \textbf{Insert/delete}: the number of messages required when a peer 
joins or leaves the network
+ \item \textbf{Number of network connections}: the number of concurrent 
network connections required to maintain correct neighbor information
 \end{itemize}
 
 \scriptsize
@@ -679,7 +666,7 @@
 \parbox{37pt}{$O$($d$)} &
 \parbox{37pt}{$O(dn^{\frac{1}{d}})$} &
 \parbox{85pt}{2$d$} &
-\parbox{85pt}{The performance of system may decrease if peers are not 
homogeneous and peers join and leave the system in a dynamic manner, where $d$ 
is the dimension of virtual key space}
+\parbox{85pt}{System performance may decrease if peers are not homogeneous and 
peers join and leave the system in a dynamic manner, where $d$ is the dimension 
of virtual key space}
 \\ \hline
 
 \parbox{37pt}{Chord \cite{stoica01chord}} &
@@ -687,7 +674,7 @@
 \parbox{37pt}{$O(\log{n}$} &
 \parbox{37pt}{$O(\log{n})$} &
 \parbox{85pt}{2$(\log{n})$} &
-\parbox{85pt}{The performance of system may decrease if peers are not 
homogeneous and peers join and leave the system in a dynamic manner}
+\parbox{85pt}{System performance may decrease if peers are not homogeneous and 
peers join and leave the system in a dynamic manner}
 \\ \hline
 
 
@@ -723,7 +710,7 @@
 \parbox{37pt}{$O$($\sqrt{n}$)} &
 \parbox{37pt}{$O(1)$} &
 \parbox{85pt}{$\frac{n}{\sqrt{n}} + c*(\sqrt{n}-1) + \frac{Totalnumber of 
files}{\sqrt{n}}$, where n is the number of peers and c the number of 
contacts/foreign affinity group} &
-\parbox{85pt}{Insert/delete overhead is constant and performed in the 
background, the performance of system may decrease if peers are not homogeneous 
and peers join and leave the system in a dynamic manner}
+\parbox{85pt}{Insert/delete overhead is constant and performed in the 
background, system performance may decrease if peers are not homogeneous and 
peers join and leave the system in a dynamic manner}
 \\ \hline
 
 \parbox{37pt}{Koorde \cite{kaashoek03koorde}} &
@@ -748,7 +735,7 @@
 \parbox{37pt}{$O(\log{n})$} &
 \parbox{37pt}{$O(\log{n})$} &
 \parbox{85pt}{$(2^{b - 1})\frac{\log{n}}{b}$, where $b$ is a configurable 
parameter for tuning digit-fixing properties (routing table)} &
-\parbox{85pt}{The performance of system performance may decrease if peers are 
not homogeneous and peers join and leave the system in a dynamic manner, based 
on Plaxton's algorithm}
+\parbox{85pt}{System performance may decrease if peers are not homogeneous and 
peers join and leave the system in a dynamic manner, based on Plaxton's 
algorithm}
 \\ \hline
 
 
@@ -797,7 +784,7 @@
 \parbox{37pt}{$O(\log{n})$} &
 \parbox{37pt}{$O(\log{n})$} &
 \parbox{85pt}{$2k+2+f$, where k = long range connections, 2 = peer's 
neighbors, f = fault tolerance connections)} &
-\parbox{85pt}{Space can be also $O(1)$. Additional space of can be used as a 
lookahead list for better performance, not necessarily fault-tolerant because 
of constant degree of neighbors}
+\parbox{85pt}{Space can also be $O(1)$. Additional space of can be used as a 
lookahead list for better performance}
 \\ \hline
 
 \parbox{37pt}{SWAN \cite{bonsma02swan}} &
@@ -814,7 +801,7 @@
 \parbox{37pt}{$O(\log{n})$} &
 \parbox{37pt}{$O(\log{n})$} &
 \parbox{85pt}{$(2^{b - 1})\frac{\log{n}}{b}$, where $b$ is a configurable 
parameter for tuning digit-fixing properties (routing table)} &
-\parbox{85pt}{The system performance may decrease if peers are not homogeneous 
and peers join and leave the system in a dynamic manner, based on Plaxton's 
algorithm}
+\parbox{85pt}{System performance may decrease if peers are not homogeneous and 
peers join and leave the system in a dynamic manner, based on Plaxton's 
algorithm}
 \\ \hline
 
 \parbox{37pt}{Viceroy \cite{malkhi02viceroy}} &
@@ -822,7 +809,7 @@
 \parbox{37pt}{$O(1)$} &
 \parbox{37pt}{$O(\log{n})$} &
 \parbox{85pt}{11} &
-\parbox{85pt}{The system performance may decrease if peers are not homogeneous 
and peers join and leave the system in a dynamic manner, not necessarily 
fault-tolerant because of constant degree of neighbors}
+\parbox{85pt}{System performance may decrease if peers are not homogeneous and 
peers join and leave the system in a dynamic manner, not necessarily 
fault-tolerant because of constant degree of neighbors}
 \\ \hline
 
 
@@ -838,34 +825,33 @@
 \chapter{Open Problems in Peer-to-Peer}
 
 In this chapter, we discuss open problems in Peer-to-Peer research. We describe
-open problems and their proposed solutions. Then, we list all issues in
-tables; we list description of the problem, solution and comments on that
-specific open problem. Note that open problems list considered here is not 
meant
+the open problems and their proposed solutions. Then, we list all issues in
+tables. 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 security, scalability, usability and performance 
issues
 only.
 
 \section{Overview}
 
-Partly due to the non-maturity of modern Peer-to-Peer technology, it has 
several
+Partly due to the non-maturity of modern Peer-to-Peer technology, there are 
several
 open problems to be solved. The most severe problems are related to 
performance, scalability, usability
-and security. More important, many techniques developed for traditional 
distributed
+and security. Also, many techniques developed for traditional distributed
 systems may no longer apply with Peer-to-Peer systems. Therefore, new 
solutions are 
 needed to make Peer-to-Peer systems more secure and efficient.
 
-Both loosely structured and tightly structured approach have their own 
specific problems. 
-Since Napster \cite{napsterurl} and Gnutella \cite{gnutellaurl} was first 
introduced 
-to public, researchers' main concern has been the scalability problem of 
loosely structured 
-approach. However, people often misunderstand the scalability problem of 
loosely structured 
+Both the loosely structured and the tightly structured approach have their own 
specific problems. 
+Since Napster \cite{napsterurl} and Gnutella \cite{gnutellaurl} were first 
introduced 
+to the public, researchers' main concern has been the scalability problem of 
the loosely structured 
+approach. However, people often misunderstand the scalability problem of the 
loosely structured 
 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 
process 
+The main concern of the tightly structured system is to make overlay's data 
lookup process 
 more fault tolerant against hostile attacks. Other key problems in tightly 
structured 
 systems are the lack of keyword searches, support for heterogeneous peers and 
load balancing
 \cite{balakrishanarticle03lookupp2p}.
 
 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 but as
+needs better infrastructures to deal with security issues. Some research has 
been done regarding 
+anonymity, access control, data availability and data integrity but as
 we state in the following sections, much more research work is required to 
solve these issues.
 
 \section{Security problems in Peer-to-Peer}
@@ -878,64 +864,63 @@
 Fail-stop attack, Spam attack \cite{naor03simpledht}, Byzantine attack 
\cite{357176} and \cite{296824}, and
 general Distributed Denial of Service attack. 
 
-In Sybil attack model, hostile entity presents multiple 
-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 the system reliably. Unfortunately,
+In Sybil attack model, a hostile entity presents multiple 
+entities. Therefore, one hostile entity can control a large fraction of the 
Peer-to-Peer system. Possible solution to 
+Sybil attack would be that the system could distinguish entities of the system 
reliably. Unfortunately,
 currently there are no realizable techniques for this task. Partial solutions 
for Sybil 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 
-authority for reliable authentication. As author argues in 
\cite{douceur02sybil}, without centralized authority, 
-Sybil attacks are always possible in Peer-to-Peer system except under extreme 
and unrealistic assumptions of 
+and fragment data randomly among several participating peers. However, both 
suggestions assume that two different 
+remote entities are actually different; Sybil attacks are still possible and 
therefore would need centralized 
+authority for reliable authentication. As the author argues in 
\cite{douceur02sybil}, without 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.
  
-In random fail-stop model, cited in \cite{naor03simpledht}, faulty peer is 
deleted from the Peer-to-Peer system.
-The reason for faultiness of peer can be a software failure, a hostile attack, 
or external threat such as virus or
-trojan. Closely related to fail-stop model is the Byzantine attack model 
-\cite{357176}. Byzantine model can be seen as more severe than fail-stop model 
as there are no restrictions over 
-the behavior of faulty peers. Practical, but partial solution for Byzantine 
failures has been proposed by Castro et 
-al. \cite{296824}. 
+In random fail-stop model, cited in \cite{naor03simpledht}, a faulty peer is 
deleted from the Peer-to-Peer system.
+The reason for the faultiness of a peer can be a software failure, a hostile 
attack, or an external threat such as virus or
+trojan. The Byzantine attack model \cite{357176} closely related to fail-stop 
model. Byzantine model can be seen as more 
+severe than fail-stop model as there are no restrictions over the behavior 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 against 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 against this attack is that peer should not trust to single 
entity. Instead, peer should get 
-information from multiple entities and trust on majority's opinion. This 
method requires more messages to be 
-sent to network while increasing system load. However, if Spam attack is 
combined with Sybil attack, obviously 
-previously mentioned solution doesn't work. Naor et al. \cite{naor03simpledht} 
have proposed a partial solution against Spam attack
+attack, a hostile or faulty peer may produce false information of the data, or 
refuses to (or is not able to) reply to requests. 
+Possible solution against this attack is that peer should not trust a single 
entity. Instead, a peer should get 
+information from multiple entities and trust on the majority's opinion. This 
method requires more messages to be 
+sent to the network while increasing the system load. However, if the Spam 
attack is combined with the Sybil attack, obviously 
+the previously mentioned solution doesn't work. Naor et al. 
\cite{naor03simpledht} have proposed a partial solution against Spam attack
 in \emph{faulty} peer environment (not hostile).
 
-Traditional overloading of targeted peers is best known form of distributed 
Denial of Service attack (DDoS). For example, 
-hostile entity can attempt to burden targeted peers with garbage network 
packets. As an implication, peers may act
-incorrectly or stop working. DDoS attack may be very severe, especially if 
rate of replication and caching 
-in Peer-to-Peer system is low. This may lead to data loss in the Peer-to-Peer 
system. Daswani et al. 
-\cite{daswani02queryflooddos} have done research regarding to this subject. 
Authors suggest efficient load balancing 
+Traditional overloading of targeted peers is the best known form of 
distributed Denial of Service attack (DDoS). For example, 
+a hostile entity can attempt to burden targeted peers with garbage network 
packets. As an implication, peers may act
+incorrectly or stop working. DDoS attack may be very severe, especially if the 
rate of replication and caching 
+in the Peer-to-Peer system is low. This may lead to data loss in the 
Peer-to-Peer system. Daswani et al. 
+\cite{daswani02queryflooddos} suggest efficient load balancing 
 policies for Peer-to-Peer system in order to prevent massive system failures. 
Sit et al. \cite{sit02securitycons} 
 suggest that identifier assignment algorithm for peers would assign identifier 
with respect to network topology 
 and replicas should be located physically to different locations.
 
 As stated in \cite{naor03simpledht}, an important aspect is that when it comes 
to general security aspects and 
 Byzantine faults in any Peer-to-Peer system, there should be a clear 
distinction between attacks on the 
-algorithms assuming the construction of overlay is correct, and attacks on the 
construction itself. Clearly, Sybil
-and Spam attack belongs to the first category, and rest of the attacks to the 
latter category.
+algorithms assuming the construction of the overlay is correct, and attacks on 
the construction itself. Clearly, Sybil
+and Spam attacks belong to the first category, and the rest of the attacks to 
the latter category.
 
 \subsection{Trust, data authenticity and integrity}
 
 Trust in Peer-to-Peer systems is based on \emph{reputation}. Proposed 
reputation methods focus either
-on the semantic properties, or the data management properties of the trust 
model. Some research has been 
+on the semantic properties or the data management properties of the trust 
model. Some research has been 
 done on reputation models in Peer-to-Peer systems, such as 
\cite{aberer01trust}, \cite{cornelli02reputableservents}. 
 One implementation include Advogato \cite{advogatourl}. None of the current 
proposals or implementations 
 based on reputation address trust in a reliable, practical way.
 
 Optimal solution for trust in Peer-to-Peer systems would be certificate based 
security models.
 Quite recently, widely used Public Key Infrastructure (PKI) has been deployed 
in distributed
-systems \cite{rivest96sdsi}, \cite{spkiworkinggroup}. PKI is reliable 
technology for securing
-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
-peers constantly join and leave the system. Specifically, the distribution of 
key changes comes an essential
+systems \cite{rivest96sdsi}, \cite{spkiworkinggroup}. PKI is a reliable 
technology for securing
+data in rather \emph{static} computing systems, such as the Internet. However, 
in Peer-to-Peer 
+networks, the problem of key based security mechanism is the maintenance of 
the keys as participating
+peers constantly join and leave the system. Specifically, the distribution of 
key changes becomes an essential
 problem in ad hoc environments. These include revocation 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. Still, however, ConChord \cite{ajmani02conchord} is 
in early phase of development and lacks of 
+security infrastructure. Still, however, ConChord \cite{ajmani02conchord} is 
in early phase of development and lacks
 important features of PKI to be fully usable yet. Furthermore, the hierarchy 
of Simple Distributed Security Infrastructure 
 (SDSI) \cite{rivest96sdsi} and Simple Public Key Infrastructure (SPKI) 
\cite{spkiworkinggroup} may be a problem for 
 Peer-to-Peer systems, in which hierarchy is intentionally missing.
@@ -944,79 +929,79 @@
 \cite{fips-sha-1}, their variations \cite{merkle87hashtree} and implementation 
techniques \cite{mohr02thex},
 are efficient and reliable methods for identifying the integrity of data in 
Peer-to-Peer systems. One
 possible application of cryptographic content hashes may be in peer identifier 
creation process, in which
-IP address of peer can be verified by the other peer. This is one form of 
\emph{self-certifying data}. 
+the IP address of a peer can be verified by the other peer. This is one form 
of \emph{self-certifying data}. 
 
 
 \subsection{Anonymity}
 
-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
-users of the system. Furthermore, peer-anonymity means that no peer can be 
linked to a specific document, i.e.,
+According to \cite{dingledine00free}, there exist several kinds of anonymity. 
Author-anonymity is a form
+of anonymity in which no one can link the author to a specific document. In 
publisher-anonymity system,
+no one is able to link the publisher to a specific document. Reader-anonymity 
means that a specific
+document cannot be linked to the readers of a document. This form of anonymity 
protects the privacy of
+the 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 the document was originally 
published. Document-anonymity
-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 forms of anonymity 
may imply each other and
-possible issues raised by this property is one area of future work.
-
-With regard to anonymity in Peer-to-Peer systems, there has been done much 
research work both at network 
-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, 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 for given data in Peer-to-Peer system. Of course, when 
we know the peers responsible
+means that a peer doesn't know which data it is currently hosting. Finally, 
query-anonymity is a form
+of document-anonymity; when other peers perform data lookups, a peer doesn't 
know which data it serves
+to the data lookup originators. As the authors cite in 
\cite{dingledine00free}, some forms of anonymity 
+may imply each other and possible issues raised by this property is one area 
of future work.
+
+With regard to anonymity in Peer-to-Peer systems, much research has been done 
both at the network 
+level layer \cite{tarzan:ccs9} and at the application level layer 
\cite{reiter98crowds}, \cite{mixminionurl}.
+Anonymity outside of Peer-to-Peer context has also been researched 
\cite{352607}, \cite{293447}.
+
+Obviously, existance 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 previously
-mentioned situations, such as pseudonym which is a partial form of anonymity. 
For instance, pseudonym can be used for 
-addressing peer-anonymity by providing anonymous-like identifiers to peers 
(e.g., peer identifiers of tightly 
+mentioned situations, such as pseudonymity which is a partial form of 
anonymity. For instance, pseudonymity can be used for 
+addressing peer-anonymity by providing anonymous-like identifiers to peers 
(e.g., peer identifiers of a tightly 
 structured system).
 
-Anonymity is widely used in those Peer-to-Peer system in which data 
publication and non-censorship are important properties
+Anonymity is widely used in Peer-to-Peer system in which data publication and 
non-censorship are important properties
 of the system. These include
-Freenet \cite{clarke00freenet}, Publius \cite{pub00}, Free haven 
\cite{dingledine00free}, Crowds \cite{reiter98crowds},
+Freenet \cite{clarke00freenet}, Publius \cite{pub00}, Free Haven 
\cite{dingledine00free}, Crowds \cite{reiter98crowds},
 Tangler \cite{502002} and upcoming Mnet \cite{mneturl}. Forwarding proxies are 
used in Freenet, Crowds and 
-Free Haven in order to provide various types of anonymity. Tangler and Publius 
uses cryptographic
+Free Haven in order to provide various types of anonymity. Tangler and Publius 
use cryptographic
 sharing methods to split data into fragments \cite{Shamir1979a}. Mix mailer 
networks, such as
 \cite{mixminionurl}, are commonly used in distributed systems, which are able 
to provide some level
 of anonymity.
 
 Even if many existing Peer-to-Peer systems are able to provide some of the 
types of anonymity, there is no
 such 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.
+between anonymity and other Peer-to-Peer system properties require more 
research work.
 
 
 \subsection{Access control}
 
-Any distributed computing system must support different levels of access 
control. For instance, in Peer-to-Peer
+Any distributed computing system must support different levels of access 
control. For instance, in a 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 do not have working and distributed access control scheme. Moreover, 
-there has been a lot of violation of copyright laws by users of Peer-to-Peer 
file sharing systems. As a 
-consequence, some law suits have been created against the companies who have 
build popular file-sharing programs.
+systems do not have a working and distributed access control scheme. Moreover, 
+there has been a lot of violations of copyright laws by users of Peer-to-Peer 
file sharing systems. As a 
+consequence, some law suits have been filed against the companies who have 
build popular file-sharing programs.
 
-To our knowledge, Nejdl et al. \cite{nejdl03accesscontrol} have proposed very 
recently first practical solution to access 
+To our knowledge, Nejdl et al. \cite{nejdl03accesscontrol} have very recently 
proposed the first practical solution to access 
 control problem in Peer-to-Peer systems. They use Resource Description 
Framework (RDF) \cite{w3rdfurl} based 
-schema policies to restrict access to certain data. Unfortunately, their 
current early prototype version works only in 
+schema policies to restrict access to certain data. Unfortunately, their 
current early prototype version only works in 
 loosely structured systems.
 
 
 \subsection{Hostile entities}
 
-One serious problem in Peer-to-Peer system is lack of ability to identify 
hostile entities trustworthy.
+One serious problem in Peer-to-Peer systems is the inability to identify 
hostile entities as trustworthy.
 Possible solutions include self-monitoring systems \cite{zhang03somo}, 
maintaining system invariants as
 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 a 
random, uniform distribution 
-of peer identifiers that cannot be controlled by hostile entity.
+content hashes (e.g., SHA-1 \cite{fips-sha-1}). 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.
 
-Of course centralized authorities could be used for assignment of peer 
identifiers, but they may not be suitable
+Naturally, 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. Moreover, distributed peer 
 identification assignment can be problematic as long as Sybil attack 
\cite{douceur02sybil} remains unsolved. 
 However, there are some partial solutions for controlling the rate at which 
hostile entity is able to obtain peer 
 identifier, such as crypto-based puzzles \cite{juels99clientpuzzles}.
 
-In the end, none of the previously mentioned solutions are able to identify 
hostile entities safely. 
+In the end, none of these problems solutions are able to identify hostile 
entities safely. 
 
 
 \subsection{Secure query routing}
@@ -1024,7 +1009,7 @@
 Much work has been done on secure routing, especially related to tightly 
structured systems. In 
 \cite{castro02securitystructured} and \cite{castro02securerouting}, authors 
suggest the usage
 of constrained routing tables and diverse routes, and detection of faults 
during query routing.
-Additionally, authors present in \cite{castro02securerouting} an important 
aspect of tightly structured approach with regard
+Additionally, authors present in \cite{castro02securerouting} an important 
aspect of the tightly structured approach with regard
 to fault-tolerant query routing: the probability of routing successfully 
between to arbitrary 
 correct peers, when a fraction $f$ of the other peers are faulty or hostile, 
is only $(1-f)^{h-1}$, where
 $h$ is the number of hops in the overlay.
@@ -1045,13 +1030,13 @@
 Peer-to-Peer system. They show that to provide high degree of fault tolerance 
and efficiency, each 
 participating peer must maintain average of $O(\log{n})$ neighbors. 
 
-Fiat et al. in \cite{fiat02censorship}, 
\cite{saia02dynamicfaultcontentnetwork} and Datar in \cite{datar02butterflies}  
+Fiat et al. in \cite{fiat02censorship, saia02dynamicfaultcontentnetwork} and 
Datar in \cite{datar02butterflies}  
 describe tightly structured overlay with analytical results in the presence of 
hostile entities. However,
 none of these proposals address an efficient, dynamic tightly structured 
overlay and multiple rounds
 of hostile attack. Also, above mentioned proposals are not very efficient. In 
\cite{fiat02censorship}, each peer 
 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
+Finally, Ratnasamy and Gavoille \cite{ratnasamy02routing, gavoille01routing} 
list several open problems
 regarding routing in distributed networks. Obviously, more research is 
required in order to provide secure
 data lookup routing possible in Peer-to-Peer networks.
 
@@ -1062,7 +1047,7 @@
 the list includes viruses and trojans. Currently, there are not even partial 
solutions
 to the problems mentioned above. General robustness properties of Peer-to-Peer 
system is able to 
 deal with software failures and hostile attack, but fault tolerance against 
external threats is unknown. 
-The reason for this is that there are no experiences on these kinds of 
attacks. Possible solution 
+The reason for this is that there are no experience on these kinds of attacks. 
Possible solution 
 would be distributed anti-virus software, but much more intensive research is 
required until
 this kind of solution would be applicable. 
 
@@ -1074,7 +1059,7 @@
 \subsection{Efficient data lookup}
 
 The most intensive research in Peer-to-Peer domain has been focused on 
efficient data lookup methods,
-especially with loosely structured approach. In addition to ''super-peer'' 
method presented in chapter
+especially with the 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 BFS searches are initiated
@@ -1116,26 +1101,25 @@
 
 Since tightly structured systems have efficient data lookup at the application 
level overlay,
 current research efforts are focused on proximity based data lookup. In 
proximity based data lookup, 
-peers try to choose routing-tables entries referring to other peers that are 
\emph{nearby} in the 
+peers try to choose entries of routing-tables referring 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 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 
+uses a combination of proximity and application level overlay routing when 
performing data 
 lookups. Authors call this feature \emph{constrained load balancing}.
 
-Additional research related to proximity based routing include 
\cite{karger02findingnearest}, 
-\cite{hildrum02distributedobject}, \cite{brinkmann02compactplacement}, 
\cite{rhea02probabilistic},
-\cite{castro02networkproximity}, \cite{ng02predicting} and 
\cite{pias03lighthouse}.
+Additional research related to proximity based routing include 
\cite{karger02findingnearest, hildrum02distributedobject, 
+brinkmann02compactplacement, rhea02probabilistic, castro02networkproximity, 
ng02predicting, pias03lighthouse}.
 
 \subsection{Fast and usable search}
 
 To make Peer-to-Peer systems even more popular (and usable), these systems 
have to support flexible, efficient
-and easy to use search methods. For instance, Internet's perhaps the most 
important feature
+and easy search methods. For instance, Internet's perhaps the most important 
feature
 is the ability to perform keyword searches (e.g., Google \cite{googleurl}). 
Currently, only loosely
 structured systems are able to carry out this requirement. Unfortunately, as 
discussed in this text,
-the data lookup model of loosely structured approach doesn't scale. Thus, 
research efforts have
+the data lookup model of the loosely structured approach doesn't scale. Thus, 
research efforts have
 been focused on tightly structured systems. The main problem with tightly 
structured systems is the 
 fact that tightly structured algorithms perform data lookups based on a 
globally unique identifier (key). 
 
@@ -1143,13 +1127,13 @@
 \cite{li03feasibility} on top of tightly structured overlays. Authors argue, 
that it is possible to implement 
 Peer-to-Peer Web-like search with certain compromises. First, Peer-to-Peer 
search engine may need to 
 decrease result quality in order to make searching more efficient. Second, 
Peer-to-Peer systems must 
-observe better the properties of underlying network for better performance. 
+observe the properties of underlying network for better performance. 
 
 Some studies have been concentrated on SQL-like queries \cite{harren02complex}
-in tightly structured overlays. Other approaches include adaption of data 
lookup model of loosely 
-structured approach into tightly structured systems 
\cite{ansaryefficientbroadcast03}, \cite{chord:om_p-meng}.
-Some studies include additional layer upon overlay network 
\cite{kronfol02fasdsearch}, 
-\cite{joseph02p2players} and range queries \cite{andrzejak02rangequeries}.
+in tightly structured overlays. Other approaches include adaption of data 
lookup model of the loosely 
+structured approach into tightly structured systems 
\cite{ansaryefficientbroadcast03, chord:om_p-meng}.
+Some studies include additional layer upon overlay network 
\cite{kronfol02fasdsearch, joseph02p2players} 
+and range queries \cite{andrzejak02rangequeries}.
 
 Many techniques have been developed in order to provide more efficient search 
indexing. As 
 several studies show, the popularity of queries in the Internet follow 
Zipf-like 
@@ -1172,14 +1156,14 @@
 
 Adaptive system management and self-organization are essential properties
 of any Peer-to-Peer system, since centralized control over the system is 
missing. Loosely structured
-systems require less system management properties than tightly structured 
systems; in loosely
+systems require less system management properties than tightly structured 
systems; in a loosely
 structured system, peers join and leave the system constantly without any 
restrictions. On the
 other hand, however, peers in tightly structured system join and leave the 
system but have less freedom, 
 i.e. overlay chooses peer's neighbors on behalf of peer itself and maps data 
items randomly 
 throughout the overlay network. 
 
 Current research has been focused on system management of tightly structured 
systems, and all presented
-algorithms of tightly structured approach have been analyzed under static 
simulation environments. Furthermore, proposed 
+algorithms of the tightly structured approach have been analyzed under static 
simulation environments. Furthermore, proposed 
 tightly structured overlays are configured statically to achieve the desired 
reliability even in uncommon and adverse environment
 \cite{rowston03controlloingreliability}. The most important factor for
 future research is to get real-life experiences from tightly structured 
systems, when there are frequent
@@ -1206,7 +1190,7 @@
 \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.
 
-As mentioned before, 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 a random, uniform 
 distribution of peer and key identifiers. Even if participating peers are 
extremely heterogeneous, e.g., in
 face of 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. Measurement study 
@@ -1217,7 +1201,7 @@
 
 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
+participating peers would create multiple hierarchical groups. It is 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.
 in \cite{rowston03controlloingreliability}. Authors propose techniques for 
self-tuning, dealing with
 uncommon conditions (e.g., network partition and high failure rates). 
Moreover, authors argue that
@@ -1243,16 +1227,15 @@
 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}.
-Early experiments with Peer-to-Peer benchmarking include 
\cite{ratnasamy02routing} and \cite{rhea03benchmarks}.
+guidelines. This list includes \cite{zhao03api, frise02p2pframework, 
babaoglu02anthill}.
+Early experiments with Peer-to-Peer benchmarking include 
\cite{ratnasamy02routing, rhea03benchmarks}.
 
 \subsection{Social behavior}
 
 Frequent assumption in Peer-to-Peer systems is that peers are willing to 
cooperate. Another belief 
 is that all peers would behave equally, i.e., all peers both consume and 
contribute resources.
 However, these assumptions are not true as several studies show. Peers rather 
consume than contribute and
-peers are unwilling to cooperate \cite{saroiu02measurementstudyp2p}, 
\cite{oram01harnessingpower}, 
-\cite{hearn02mojonation}. 
+peers are unwilling to cooperate \cite{saroiu02measurementstudyp2p, 
oram01harnessingpower, hearn02mojonation}. 
 
 Somewhat surprisingly little research has been done in this area, especially 
when considering 
 the possible impact of \emph{unwanted social behavior} to performance of 
Peer-to-Peer 
@@ -1271,7 +1254,7 @@
 Very little research has been done on simulating a Peer-to-Peer system. 
Presumably, this
 is due to complex nature of Peer-to-Peer system, which makes comprehensive 
simulations very 
 difficult. 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
+state that simulating the Internet is very challenging task, because of its 
heterogeneity
 and rapid change. Obviously, these factors exist also in Peer-to-Peer systems 
even with higher
 rates.
 
@@ -1317,22 +1300,22 @@
 
 
 
-\parbox{90pt}{Query routing \cite{sit02securitycons}, 
\cite{aspnes02faultrouting}, \cite{castro02securerouting}, 
\cite{ratnasamy02routing}, \cite{gavoille01routing}, 
-\cite{lynch02atomicdataaccess}, \cite{fiat02censorship}, 
\cite{saia02dynamicfaultcontentnetwork}, \cite{datar02butterflies}} &           
      
+\parbox{90pt}{Query routing \cite{sit02securitycons, aspnes02faultrouting, 
castro02securerouting, ratnasamy02routing, gavoille01routing,
+lynch02atomicdataaccess, fiat02censorship, saia02dynamicfaultcontentnetwork, 
datar02butterflies}} &                    
 \parbox{110pt}{Incorrect forwarding (hostile), incorrect routing (hostile)} &
 \parbox{110pt}{Query monitoring, cross check routing tables, verify routing 
tables, create routing table invariants} &
 \parbox{110pt}{Increases system complexity} 
 \\ \hline
 
 
-\parbox{90pt}{DoS attack \cite{sit02securitycons}, 
\cite{saia02dynamicfaultcontentnetwork}, \cite{datar02butterflies}, 
\cite{daswani02queryflooddos}, \cite{juels99clientpuzzles}} &
+\parbox{90pt}{DoS attack \cite{sit02securitycons, 
saia02dynamicfaultcontentnetwork, datar02butterflies, daswani02queryflooddos, 
juels99clientpuzzles}} &
 \parbox{110pt}{Distributed, controlled burden against specific computer(s)} &
 \parbox{110pt}{Client puzzles, load balancing, traffic measurements, traffic 
models, replication} &
 \parbox{110pt}{Only partial solutions, traffic models most effective}
 \\ \hline 
 
 
-\parbox{90pt}{Sybil attack \cite{douceur02sybil}, 
\cite{castro02securerouting}} &
+\parbox{90pt}{Sybil attack \cite{douceur02sybil, castro02securerouting}} &
 \parbox{110pt}{Single hostile entity presents multiple entities} &
 \parbox{110pt}{Identify all peers simultaneously across the system, collect 
pool of peers which are validated, distributed peer ID creation} &
 \parbox{110pt}{Not practically realizable, research focused on persistence, 
not on identity distinction}
@@ -1360,21 +1343,21 @@
 \\ \hline
 
 
-\parbox{90pt}{Anonymity \cite{dingledine00free}, \cite{tarzan:ccs9}, 
\cite{pub00}, \cite{clarke00freenet}, \cite{reiter98crowds}, 
\cite{352607},\cite{502002}} &
+\parbox{90pt}{Anonymity \cite{dingledine00free, tarzan:ccs9, pub00, 
clarke00freenet, reiter98crowds, 352607, 502002}} &
 \parbox{110pt}{Anonymity cannot be provided in all cases} &
 \parbox{110pt}{Remailers, pre-routing} &
 \parbox{110pt}{Total anonymity cannot be provided yet}
 \\ \hline
 
 
-\parbox{90pt}{Malicious peers \cite{sit02securitycons}, 
\cite{castro02securerouting}} &
+\parbox{90pt}{Malicious peers \cite{sit02securitycons, castro02securerouting}} 
&
 \parbox{110pt}{How to identify malicious peers in the system ?} &
 \parbox{110pt}{Create invariants for peer behavior, verify invariants, 
self-certifying data} &
 \parbox{110pt}{Partial solutions, self-certifying data most reliable}
 \\ \hline
 
 
-\parbox{90pt}{Access Control \cite{nejdl03accesscontrol}, 
\cite{daswani03openproblems}} &
+\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}
@@ -1432,33 +1415,32 @@
 
 \endfoot
                
-\parbox{90pt}{Web indexing and searching \cite{li03feasibility}, 
\cite{Bhattacharjee03resultcache}, \cite{362692}, 
\cite{CuencaAcuna2002DSIWorkshop}, 
-\cite{rhea02probabilistic}, \cite{joseph02neurogrid}, 
\cite{crespo02semanticoverlay}, \cite{joseph02p2players}, 
\cite{chord:om_p-meng},
-\cite{wittengigabytes}, \cite{338634}} &
+\parbox{90pt}{Web indexing and searching \cite{li03feasibility, 
Bhattacharjee03resultcache, 362692, CuencaAcuna2002DSIWorkshop, 
+rhea02probabilistic, joseph02neurogrid, crespo02semanticoverlay, 
joseph02p2players, chord:om_p-meng, wittengigabytes, 338634}} &
 \parbox{110pt}{Perform Web like searches in Peer-to-Peer network} &
 \parbox{110pt}{Data compression, view trees, bloom filters and its variations, 
gap compression, index intersection optimizations, clustering} &
 \parbox{110pt}{Effective but complex solutions, some compromises have to be 
done (decrease result quality, modify overlay's structure), more research 
needed}
 \\ \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{ramanathan02goodpeers}, \cite{kleinberg99small}, 
\cite{nips02-Kleinberg}, \cite{zhang02using}, \cite{watts00dynamics}, 
\cite{karger02findingnearest}, 
-\cite{brinkmann02compactplacement}, \cite{rhea02probabilistic}, 
\cite{castro02networkproximity}, \cite{ng02predicting}, 
\cite{pias03lighthouse}} &
+\parbox{90pt}{Efficient and scalable data discovery 
\cite{lv02searchreplication, osokine02distnetworks, yang02improvingsearch, 
lv02gnutellascalable, 
+ganesan02yappers, adamic02localsearch, adamic01powerlawsearch, 
ripeanu02mappinggnutella, milgram67smallworld, adamic99small, 
+ramanathan02goodpeers, kleinberg99small, nips02-Kleinberg, zhang02using, 
watts00dynamics, karger02findingnearest, 
+brinkmann02compactplacement, rhea02probabilistic, castro02networkproximity, 
ng02predicting, pias03lighthouse}} &
 \parbox{110pt}{Find resources 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
 
 
-\parbox{90pt}{Richness of queries \cite{harren02complex}, 
\cite{ansaryefficientbroadcast03}, \cite{andrzejak02rangequeries}} &
+\parbox{90pt}{Richness of queries \cite{harren02complex, 
ansaryefficientbroadcast03, andrzejak02rangequeries}} &
 \parbox{110pt}{Query languages should be more powerful in tightly structured 
overlays} &
 \parbox{110pt}{SQL-like queries} &
 \parbox{110pt}{Hard to implement, increases system complexity, not much 
research has been done}
 \\ \hline
 
 
-\parbox{90pt}{Robustness \cite{datar02butterflies}, 
\cite{saia02dynamicfaultcontentnetwork}, \cite{fiat02censorship}, 
\cite{aspnes02faultrouting}, \cite{albert-00-tolerance}, 
\cite{libennowell01observations}} &
+\parbox{90pt}{Robustness \cite{datar02butterflies, 
saia02dynamicfaultcontentnetwork, fiat02censorship, aspnes02faultrouting, 
albert-00-tolerance, libennowell01observations}} &
 \parbox{110pt}{How well system performs under hostile attacks/in the case of 
severe failure ?} &
 \parbox{110pt}{Self-tuning, backup links, use diverse routing paths, power-law 
networks/properties} &
 \parbox{110pt}{Working solutions}
@@ -1479,46 +1461,46 @@
 \\ \hline
 
 
-\parbox{90pt}{Network proximity \cite{pias03lighthouse}, 
\cite{ng02predicting}, \cite{ratnasamy02ght}, \cite{eriksson03peernet}, 
\cite{castro02networkproximity}} &
+\parbox{90pt}{Network proximity \cite{pias03lighthouse, ng02predicting, 
ratnasamy02ght, eriksson03peernet, castro02networkproximity}} &
 \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
 
 
-\parbox{90pt}{Locality \cite{keleher-02-p2p}, 
\cite{hildrum02distributedobject}, \cite{freedman02trie}, 
\cite{sloppy:iptps03}, \cite{plaxton97accessingnearby}, 
\cite{karger02findingnearest}} &
+\parbox{90pt}{Locality \cite{keleher-02-p2p, hildrum02distributedobject, 
freedman02trie, sloppy:iptps03, plaxton97accessingnearby, 
karger02findingnearest}} &
 \parbox{110pt}{Could tightly structured systems exploit locality properties 
better ?} &
 \parbox{110pt}{Constrained Load Balancing, using network properties for 
nearest neighbor selection, self-organizing clusters} &
 \parbox{110pt}{Working solutions}
 \\ \hline
 
 
-\parbox{90pt}{Hot spots \cite{258660}, \cite{sloppy:iptps03}, 
\cite{maymounkov03ratelesscodes}} &
+\parbox{90pt}{Hot spots \cite{258660, sloppy:iptps03, 
maymounkov03ratelesscodes}} &
 \parbox{110pt}{What will happen if some resource is extremely popular and only 
one peer is hosting it ?} &
 \parbox{110pt}{Caching, multisource downloads, replication, load balancing, 
sloppy hashing} &
 \parbox{110pt}{For query hot spots, caching and multisource downloads 
efficiently reduce hot spots, for routing hot spots, benefits are smaller}
 \\ \hline
 
 
-\parbox{90pt}{Load balancing \cite{rao03loadbalancing}, 
\cite{ledlie02selfp2p}, \cite{byers03dhtbalancing}} &
+\parbox{90pt}{Load balancing \cite{rao03loadbalancing, ledlie02selfp2p, 
byers03dhtbalancing}} &
 \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
 
-\parbox{90pt}{System in flux \cite{libennowell01observations}, \cite{571863}, 
\cite{ledlie02selfp2p}, \cite{albert-02-statistical}} &
+\parbox{90pt}{System in flux \cite{libennowell01observations, 571863, 
ledlie02selfp2p, albert-02-statistical}} &
 \parbox{110pt}{Peers join and leave system constantly. What about load 
balancing and performance ?} &
 \parbox{110pt}{Half-life phenomenon (for analysis), simple overlay maintenance 
and construction algorithm} &
 \parbox{110pt}{Initial theoretical analysis have been created, but not 
comprehensive model for analyzing different system states and its variations 
(e.g. complex usage patterns)}
 \\ \hline
 
-\parbox{90pt}{Sudden network partition \cite{harvey03skipnet1}, 
\cite{harvey03skipnet2}, \cite{rowston03controlloingreliability}} &
+\parbox{90pt}{Sudden network partition \cite{harvey03skipnet1, 
harvey03skipnet2, rowston03controlloingreliability}} &
 \parbox{110pt}{Sub network is isolated from other network because of network 
disconnection} &
 \parbox{110pt}{Self-tuning, environment observation, localized network 
connection for minimum latency (backup connections)} &
 \parbox{110pt}{Creates more overhead/space requirements per peer}
 \\ \hline
 
-\parbox{90pt}{Fail Stop \cite{rowston03controlloingreliability}, 
\cite{zhang03somo}} &
+\parbox{90pt}{Fail Stop \cite{rowston03controlloingreliability, zhang03somo}} &
 \parbox{110pt}{A faulty peer stops working} &
 \parbox{110pt}{Failure detectors, informing algorithms} &
 \parbox{110pt}{Creates more network traffic, peer's information can be 
outdated, failure detectors not reliable}
@@ -1563,28 +1545,28 @@
 \endfoot
 
 
-\parbox{90pt}{Mutual distrust \cite{cornelli02reputableservents}, 
\cite{aberer01trust}} &
+\parbox{90pt}{Mutual distrust \cite{cornelli02reputableservents, 
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}
 \\ \hline
 
 
-\parbox{90pt}{Lack of motivation to cooperate \cite{golle01incentivesp2p}, 
\cite{ngan03enforcefile}, \cite{shneidman03rationality}} &
+\parbox{90pt}{Lack of motivation to cooperate \cite{golle01incentivesp2p, 
ngan03enforcefile, shneidman03rationality}} &
 \parbox{110pt}{All participants do not behave like they should be, instead 
they go for own profit} &
 \parbox{110pt}{Different reputation methods} &
 \parbox{110pt}{No real world experience in a wide scale}
 \\ \hline
 
 
-\parbox{90pt}{Heterogeneity \cite{saroiu02measurementstudyp2p}, 
\cite{brinkmann02compactplacement}, 
\cite{zhao02brocade},\cite{gurmeet03symphony}, 
\cite{rowston03controlloingreliability}} &
+\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}{Working solutions, increases system complexity (additional 
layer)}
 \\ \hline
 
 
-\parbox{90pt}{Programming guidelines \cite{zhao03api}, 
\cite{frise02p2pframework}, \cite{babaoglu02anthill}, \cite{rhea03benchmarks}, 
\cite{garciamolina03sil}, \cite{balakrishnan03semanticfree}} &
+\parbox{90pt}{Programming guidelines \cite{zhao03api, frise02p2pframework, 
babaoglu02anthill, rhea03benchmarks, garciamolina03sil, 
balakrishnan03semanticfree}} &
 \parbox{110pt}{Set of programming guidelines/frameworks is needed for better 
interoperability between different systems} &
 \parbox{110pt}{Common frameworks and APIs} &
 \parbox{110pt}{Common framework/API is still missing, a few proposals have 
been made (tightly structured)}
@@ -1599,9 +1581,9 @@
 
 
 \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}{System is self-capable to monitor it is 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 (loosely 
structured)} &
-\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}
+\parbox{110pt}{For tightly structured overlays, efficient and simple to 
implement, fault tolerance unknown, for the loosely structured approach not 
necessarily efficient because decisions are based on local knowledge}
 \\ \hline
 
 \parbox{90pt}{Locating Peer-to-Peer network} &
@@ -1620,26 +1602,26 @@
 
 \chapter{Fenfire hypermedia system}
 
-In this chapter we give an overview of Fenfire system. We also 
+In this chapter we give an overview of the Fenfire system. We also 
 describe briefly xanalogical storage model. At the end of this chapter we 
study Storm, 
 Fenfire's software module, which is an essential part of Fenfire's 
Peer-to-Peer 
 functionality. 
 
 \section{Overview}
 
-Fenfire project \cite{fenfireurl} is an effort to build a location 
transparent, hyperstructured desktop 
-environment. Fenfire's uses xanalogical storage model \cite{ted-xu-model} as a 
basis for hyperstructured
-media. Fenfire uses innovative user interfaces for displaying data to the end 
users. All data in Fenfire
-is stored in same format, i.e., blocks. This should allow making references 
between data easier and more 
+The Fenfire project \cite{fenfireurl} is an effort to build a location 
transparent, hyperstructured desktop 
+environment. Fenfire uses xanalogical storage model \cite{ted-xu-model} as a 
basis for hyperstructured
+media. Fenfire deploys innovative user interfaces for displaying data to the 
end users. All data in the Fenfire
+is stored in a unified format, i.e., blocks. This should allow making 
references between data easier and more 
 seamlessly interoperating than in other systems. For location transparency in 
a distributed system, Fenfire 
 uses Peer-to-Peer network for locating and fetching blocks.
 
-Fenfire is free software and it is licensed under GNU L-GPL.  Fenfire was 
formerly also a partial implementation 
+Fenfire is free software and it is licensed under GNU LGPL.  Fenfire was 
formerly also a partial implementation 
 of the ZigZag\texttrademark --structure, which was originally invented 
 by Ted Nelson. Now, however, Fenfire uses Resource Description Framework (RDF) 
\cite{w3rdfurl}
 for representing internal data structures and their relationships. 
 
-Fenfire is high modular software system. It consists of several independent 
software modules:
+Fenfire is a high modular software system. It consists of several independent 
software modules:
 
 \begin{itemize}
 \item \textbf{Storm}: distributed storage module for storing arbitrary data 
items
@@ -1652,9 +1634,9 @@
 
 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' 
when referring to both
-Storm and Alph software modules. For location transparency in Fenfire system, 
Storm software module 
+Storm and Alph software modules. For location transparency in the Fenfire 
system, Storm software module 
 must have support for Peer-to-Peer functionality as it provides low-level data 
storage operations
-in Fenfire system.
+in the Fenfire system.
 
 
 \section{Xanalogical storage model}
@@ -1683,7 +1665,7 @@
 and bidirectional. Xanadu link is an \emph{association} of two enfilades, such 
as an 
 annotation to a specific part of a another document. \emph{Transclusion} is an 
inclusion in 
 enfilade of contents already used in another enfilade, i.e., current fluid 
media is copied into 
-different data contents. By using this mechanism, system implementing 
xanalogical storage model
+different data contents. By using this mechanism, a system implementing 
xanalogical storage 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 storage model with documents, text and characters.
@@ -1703,7 +1685,7 @@
 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
+Storm (for \emph{STORage Module}) is a software module, which is used in the 
Fenfire for
 data storage operations. Storm stores all data as \emph{blocks}, which
 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 
@@ -1713,7 +1695,7 @@
 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., 
globally unique 
 identifier. This mechanism creates a basis for implementing xanalogical 
storage model in 
-Fenfire system. Figure \ref{fig:storm_model} illustrates simplified Storm 
storage model.
+in Fenfire system. Figure \ref{fig:storm_model} illustrates simplified Storm 
storage model.
 
 \begin{figure}
 \centering
@@ -1730,8 +1712,8 @@
  
 Pointer \cite{benja02urn5} is a semantic-free, updatable reference to 
 Storm data block, i.e., Storm scroll block. 
-In practice, pointer is random string, which resembles Universal Resource 
Names 
-(URN) \cite{rfc2396}. Pointer itself doesn't contain any data, it's rather a 
\emph{concept} of
+In practice, pointer is a random string, which resembles Universal Resource 
Names 
+(URN) \cite{rfc2396}. Pointer itself doesn't contain any data, it is rather a 
\emph{concept} of
 data. Pointers are created automatically by Storm and each pointer is 
 associated with a collection of \emph{pointer blocks}. Pointer block has a 
single 
 target for the pointer. In figure \ref{fig:storm_model}, we present overall 
@@ -1755,10 +1737,10 @@
 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. We define Fenfire's special needs and evaluate existing 
-Peer-to-Peer approaches in light of these requirements. After that, we propose 
system
+Peer-to-Peer approaches in light of these requirements. After that, we propose 
a system
 model for Fenfire in Peer-to-Peer environment and present simple methods to 
perform data 
 lookups in Peer-to-Peer environment. In the end of this chapter, we discuss 
possible problems of using Fenfire
-in Peer-to-Peer environment
+in Peer-to-Peer environment.
 
 
 \section{Problem overview}
@@ -1770,7 +1752,7 @@
 from fragments of data. 
 
 In the xanalogical storage model, each fragment of data is identified by a 
globally 
-unique identifier. In Fenfire, data fragments are scroll blocks, generated by 
Storm storage module.
+unique identifier. In the Fenfire system, data fragments are scroll blocks, 
generated by Storm storage module.
 As we discussed already in chapter 4, Fenfire's Storm design 
 uses SHA-1 \cite{fips-sha-1} hash over the contents of a scroll block for 
creating globally unique 
 identifiers for each scroll block.  In our scenario, fragments of data is 
distributed 
@@ -1808,17 +1790,17 @@
 \section{Evaluation of Peer-to-Peer approaches with regard to Fenfire}
 
 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 
+approaches. As stated, the most significant difference is that the tightly 
structured 
+approach has logarithmical properties in all internal operations, while the 
loosely 
 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
+in the overlay, whereas the data lookup model of the loosely structured 
approach
 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, an important advantage 
of 
-tightly structured approach over loosely structured approach is that tightly 
+For Fenfire's special needs for \emph{locating} data, an important advantage 
of the 
+tightly structured approach over the loosely structured approach is that 
tightly 
 structured systems use location-independent, globally unique identifiers for 
 identifying data in the system. Indeed, this 
 feature is almost analogical to Fenfire's (and xanalogical storage model's) 
way of 
@@ -1827,17 +1809,17 @@
 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}. Finally, as said, with tightly structured systems, it is 
feasible to 
+\emph{semantically 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 distributed, 
location transparent hypermedia system.
 Thus, we see the tightly structured approach as the best alternative to locate 
data in Peer-to-Peer
 environment.
 
-Once located, for \emph{fetching} Fenfire related data from the overlay, we 
can use regular 
+Once located, for \emph{fetching} Storm blocks from the overlay, we can use 
regular 
 TCP/IP-protocols, such as Hypertext Transfer protocol (HTTP) \cite{rfc2068}. 
However, HTTP-protocol may 
 not be optimal when obtaining large amounts of data from the Peer-to-Peer 
network (e.g., 
 videos, images or music). In this case, multisource downloads can be very 
useful 
-for better efficiency \cite{maymounkov03ratelesscodes}, \cite{bittorrenturl}. 
Furthermore, 
+for better efficiency \cite{maymounkov03ratelesscodes, bittorrenturl}. 
Furthermore, 
 multisource downloads can be used for decreasing load of certain peer, thus 
avoiding query 
 hot spots in the system \cite{ratnasamy02routing}. Current implementation of 
Fenfire uses 
 standard single source downloads (HTTP) and SHA-1 \cite{fips-sha-1} 
cryptographic content 
@@ -1846,7 +1828,7 @@
 tree-based hash\footnote{With multisource downloads, tree based hash functions 
can be used 
 to verify fixed length segments of data. If hash value of data segment is 
incorrect, 
 we need only to fetch \emph{segment} of data (instead of whole data, e.g., a 
file) from 
-other source.}, such as \cite{merkle87hashtree} and \cite{mohr02thex} for 
reliable and efficient 
+other source.}, such as \cite{merkle87hashtree, mohr02thex} for reliable and 
efficient 
 data validation.
 
 Again, there are research challenges with tightly structured systems which 
have to be
@@ -1854,7 +1836,7 @@
 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 
+(e.g., \cite{overneturl, edonkey2kurl}). Therefore, we can't say for sure, how 
well these 
 systems would perform in real Peer-to-Peer environment. However, we believe 
that issues are 
 solved, since there is a strong and wide research community towards to tightly 
structured 
 overlays \cite{projectirisurl}.
@@ -1872,8 +1854,8 @@
 locating data efficiently in the Peer-to-Peer overlay. There are two main
 reasons for this. First, Kademlia's XOR-based distance function is superior
 over the distance functions of other systems (see section 2.4). Second, there 
exist already  
-deployed real-life systems using Kademlia (e.g., \cite{overneturl}, 
\cite{edonkey2kurl}, \cite{kashmirurl},
-\cite{kato02gisp}), which means that Kademlia's algorithm is simple and easy 
to implement.
+deployed real-life systems using Kademlia (e.g., \cite{overneturl, 
edonkey2kurl, kashmirurl,
+kato02gisp}), which means that Kademlia's algorithm is simple and easy to 
implement.
 
 On top of Kademlia, we propose the usage of Sloppy hashing 
\cite{sloppy:iptps03} which
 is optimized for the DOLR abstraction of tightly structured overlays. With the 
Sloppy hashing, 
@@ -1895,15 +1877,15 @@
 
 \subsection{Methods}
 
-We use the DOLR abstraction of tightly structured approach, i.e., each 
participating peer hosts 
+We use the DOLR abstraction of the 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 the DOLR 
 abstraction 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 be able to store relatively large amount of data with key/value 
pair, assigned randomly by 
-mapping function of the overlay. These systems wastes both storage and 
bandwidth, and
+mapping function of the overlay. These systems waste both storage and 
bandwidth, and
 are sensitive to certain attacks (e.g., DDoS attack). Additionally, we 
emphasize that we prefer \emph{abstraction}
-level analysis as very recently better and better tightly structured 
algorihtms have been proposed. 
+level analysis as very recently better and better tightly structured 
algorithms have been proposed. 
 Thus, we don't want to bind our system proposal to a specific algorithm 
definitively as we expect 
 that this development continues.
 
@@ -1934,7 +1916,7 @@
 \end{itemize}
 
 Figure \ref{fig:storm_query_blockid} illustrates how Storm scroll block is 
located 
-in a tightly structured overlay using the DOLR abstraction, where identifier 
of Storm scroll 
+in tightly structured overlay using the DOLR abstraction, where identifier of 
Storm scroll 
 block is known.
 
 
@@ -1959,9 +1941,9 @@
 \end{itemize}
 
 Figure \ref{fig:storm_query_urn5} illustrates how Storm scroll block is 
located 
-in a tightly structured overlay using the DOLR abstraction, where pointer 
random string is known.
+in tightly structured overlay using the DOLR abstraction, where pointer random 
string is known.
 
-Each of these algorithms can locate Fenfire related data in $O(\log{n})$ time 
at application level overlay:
+Each of these algorithms can locate Fenfire data in $O(\log{n})$ time at 
application level overlay:
 $O(\log{n})$ time for query routing to pointer peer and constant time for 
 locating hosting peer with a given reference link.
 
@@ -1987,18 +1969,18 @@
 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 the user is able to verify the correctness
-of the search results ? Specifically, how she/he knows which one is the 
+pointer random string; how can the user verify the correctness
+of the search results ? Specifically, how she or he knows which one is the 
 correct Storm scroll block ? Spam attack \cite{naor03simpledht} is a variation 
of previously
 mentioned problem; data lookup is performed by a user, but there is no reply
-from the system. How we are able to know if this was a spam attack, or the
-data really doesn't exist in the system ? Another problem related to Fenfire's 
+from the system. How are we able to know if this was a spam attack, or the
+data really doesn't exist in the system ? Another problem related to the 
Fenfire's 
 security is that if a user downloads data from the network to local computer 
 and after network disconnection, user wants to verify \emph{off line} the 
 authenticity of data. Obviously, optimal solution to all security issues would 
 be that digital signatures are included to every message sent to the system 
therefore 
 enabling peers to authenticate other peers safely. However, these problems are 
not 
-only limited to Fenfire as it concerns all Peer-to-Peer based computer systems.
+only limited to the Fenfire as it concerns all Peer-to-Peer based computer 
systems.
 
 As security technologies come more mature, we wish to apply these 
 technologies with Fenfire, if applicable.
@@ -2013,11 +1995,11 @@
 yet, or solutions are only partial. We point out that much research work is 
required to
 solve these problems.
 
-Then, we focused our attention to Fenfire system. First, we gave a brief
+Then, we focused our attention to the Fenfire system. First, we gave a brief
 overview of Fenfire and xanalogical model. We also described Storm software 
module.
 
 In the last chapter, we evaluated existing Peer-to-Peer approaches with regard
-to Fenfire's needs. We proposed that tightly structured approach is the
+to Fenfire's needs. We proposed that the 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} 
@@ -2027,7 +2009,7 @@
 we also agree that tightly structured overlays provide general purpose
 interface to next-generation reference resolution services. Third, by using 
 the DOLR abstraction of tightly structured overlay, we can minimize the lack 
-of locality in tightly structured approach. Finally, we believe that issues 
+of locality in the 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.
 




reply via email to

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