[Gzz-commits] gzz/Documentation/misc/hemppah-progradu researc...

[Hermanni Hyytiälä]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Hermanni Hyytiälä <address@hidden>      03/01/24 08:24:27

Modified files:
        Documentation/misc/hemppah-progradu: research_problems 

Log message:
        Some answers to Tuomas' scenarios

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/Documentation/misc/hemppah-progradu/research_problems.diff?tr1=1.33&tr2=1.34&r1=text&r2=text

Patches:
Index: gzz/Documentation/misc/hemppah-progradu/research_problems
diff -u gzz/Documentation/misc/hemppah-progradu/research_problems:1.33 
gzz/Documentation/misc/hemppah-progradu/research_problems:1.34
--- gzz/Documentation/misc/hemppah-progradu/research_problems:1.33      Fri Jan 
24 06:30:38 2003
+++ gzz/Documentation/misc/hemppah-progradu/research_problems   Fri Jan 24 
08:24:27 2003
@@ -798,15 +798,31 @@
 floodaamalla indeksi
 mutta sitten poistamalla ne serverit
 
+Solutions:
+1) periodically (cross) checking the consistency of routing tables with 
randomly chosen other nodes
+
 Tuomas' example scenario #2:
 'What will happen if, jyu's network connection is broken ? Inside jyu network, 
how do we/system will self-organise ?'
 
+Tuomas' example scenario #3:
+'What will happen if a malicious node quantities large amounts of data in the 
system ?'
+
+Solutions:
+1) centralized: Per node based quotas based on reliable identification of 
publishers (usually requires CAs to work correctly)
+2) decentralized: Per node based quotas based on the ip address of the node
+
 It seems to be that DHTs are unable to self-reorganise after a sudden 
partitioning, because
 a) every node has a fixed space in identifier space
 b) system has a fixed identifier space, e.g. Pastry and Chord require a priori 
knowledge about the size of the system
 c) even if system is able self-reorganise, the key space is not uniformly 
distributed anymore -> all nodes have to leave/rejoin --> lot of traffic
 
-The question is: how well SWAN can self-organise ?
+To ensure data availability:
+System myst maintain the desired level of replcation as nodes join and leave 
the system in order to. If nodes often join/leave the system
+for a short time before leaving (i.e. short 'half-life'), replicas will be 
wasted. Therefore, system should have a support foe lazy replica
+copying
+
+
+The question is: how well SWAN can self-organise, e.g. in the case of Tuomas' 
scanario #2 ?
 
 Half-life phenomenon \cite{libennowell01observations}
 Current decentralized, but structured \cite{chord, can, pastry, Tapestry etc.) 
ignores the fact 
@@ -853,7 +869,7 @@
 Main problems in different approaches (own conclusions, based on research 
efforts):
 1) Decentralized, but structured
 -make routing/system more flexible againts adversial attacks
-       -e.g. -there is a single point of routing failure in these approaches 
(h hops, little amount f of system are adversial)
+       -e.g. -there is a single point of routing failure in these approaches 
(h hops, little amount f of system are adversial) 
 -make searching/query model more flexible (keyword searching)
        -use keywords/range searches instead of exact keys
        proposal for range searches: Scalable, Efficient Range Queries for Grid 
Information Services \cite{andrzejak02rangequeries}