[Top][All Lists]
[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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu applica...,
Hermanni Hyytiälä <=