[Gzz-commits] storm/doc/pegboard/storm_gisp_simulation--hempp...

[Hermanni Hyytiälä]

CVSROOT:        /cvsroot/storm
Module name:    storm
Changes by:     Hermanni Hyytiälä <address@hidden>      03/06/05 04:38:09

Modified files:
        doc/pegboard/storm_gisp_simulation--hemppah: peg.rst 

Log message:
        Updates...

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/storm/storm/doc/pegboard/storm_gisp_simulation--hemppah/peg.rst.diff?tr1=1.12&tr2=1.13&r1=text&r2=text

Patches:
Index: storm/doc/pegboard/storm_gisp_simulation--hemppah/peg.rst
diff -u storm/doc/pegboard/storm_gisp_simulation--hemppah/peg.rst:1.12 
storm/doc/pegboard/storm_gisp_simulation--hemppah/peg.rst:1.13
--- storm/doc/pegboard/storm_gisp_simulation--hemppah/peg.rst:1.12      Wed Jun 
 4 08:50:18 2003
+++ storm/doc/pegboard/storm_gisp_simulation--hemppah/peg.rst   Thu Jun  5 
04:38:09 2003
@@ -5,8 +5,8 @@
 
 :Authors:  Hermanni Hyytiälä
 :Date-Created: 2003-06-02
-:Last-Modified: $Date: 2003/06/04 12:50:18 $
-:Revision: $Revision: 1.12 $
+:Last-Modified: $Date: 2003/06/05 08:38:09 $
+:Revision: $Revision: 1.13 $
 :Status:   Incomplete
 
 .. :Stakeholders:
@@ -106,8 +106,31 @@
       between peers
     - some form of formal analyses ("proofs") are used, 
       e.g., with Chord and Kademlia
-    - distribution of number of peers used in simulations: from 2^7 to 2^20 
+    - distribution of number of peers used in simulations: from 2^7 to 2^20
     
+    
+ISSUE: 
+   
+    What is known or easily deducible about the effect of a single
+    hostile node? Following variants:
+
+    - Node just wants to make the network work slower
+
+    - Node wants to make searches for some particular informations difficult
+
+    - Node wants to make life difficult for some particular nodes,
+      slowing down their queries
+
+    - Node wants to make search for particular information by particular nodes
+      difficult
+
+    - Node wants to spam a particular identifier or xu block
+    
+    
+ISSUE: 
+ 
+   Do we want to keep GISP or move to Kademlia or some other?
+   
 Plan
 ====
 
@@ -137,10 +160,10 @@
 Chord's routing table is rigid compared to Kademlia's routing table.
 
 Since GISP lacks of Kademlia's binary-tree-like abstraction of the routing 
-table, it is evident that the benefits of Kademlia's lookup properties (over 
-other DHTs) are not available in the GISP protocol, e.g., no concurrent and
+table, it is clear that the benefits of Kademlia's lookup properties (over 
+other DHTs) are *not available* in the GISP protocol, e.g., no concurrent and
 asynchronous lookups (no free of choice) and when a peer leaves the system
-no messages are required.
+no messages are required. 
 
 Original GISP publication describes "peer strength" as a measure for peer 
 heteregeneity but do not describe what properties are used and how this
@@ -159,11 +182,11 @@
   
 - What about GISP's lookup effieciency when the network grows ?
 
-- GISP does not use Kademlia's binary-tree abstraction - does it have 
influences 
-  and if it does what are the influences ? 
+- GISP does not use Kademlia's binary-tree abstraction - does it have negative 
+  influences and if it does what are the (bad) influences ? 
   
 - How much better/worse pure Kademlia implementation (e.g. Kashmir) is over 
the GISP 
-  protocol in face performance and fault-tolerance ?
+  protocol in face of performance and fault-tolerance ?
          
 - How well GISP is able to perform in adverse conditions, e.g., a
   network partition occurs ?