[Gzz-commits] storm/doc/pegboard/attacking_gisp--hemppah peg.rst

[Hermanni Hyytiälä]

CVSROOT:        /cvsroot/storm
Module name:    storm
Branch:         
Changes by:     Hermanni Hyytiälä <address@hidden>      03/06/10 06:34:53

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

Log message:
        scenario description

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

Patches:
Index: storm/doc/pegboard/attacking_gisp--hemppah/peg.rst
diff -u storm/doc/pegboard/attacking_gisp--hemppah/peg.rst:1.13 
storm/doc/pegboard/attacking_gisp--hemppah/peg.rst:1.14
--- storm/doc/pegboard/attacking_gisp--hemppah/peg.rst:1.13     Fri Jun  6 
08:10:05 2003
+++ storm/doc/pegboard/attacking_gisp--hemppah/peg.rst  Tue Jun 10 06:34:53 2003
@@ -5,8 +5,8 @@
 
 :Authors:  Hermanni Hyytiälä
 :Date-Created: 2003-06-05
-:Last-Modified: $Date: 2003/06/06 12:10:05 $
-:Revision: $Revision: 1.13 $
+:Last-Modified: $Date: 2003/06/10 10:34:53 $
+:Revision: $Revision: 1.14 $
 :Status:   Incomplete
 
 .. :Stakeholders:
@@ -67,7 +67,42 @@
    so start with the dumb peer and specify it exactly. Then run 
    the test.
    
-Scenario
+Scenario #1 (static "dumb"):
+
+Description:
+In this scenario, we use "dumb" peers to test GISP's fault tolerance.
+In this context with "dumb" peers we mean peers which do not reply or
+forward queries at all. There are two variations of this scenario. The first
+variation is the static scenario in which peers do join or leave the system 
while
+the test is running. In the second variation, peers can join and leave the
+system while the test is running. 
+
+We expect that GISP is able to route some queries to their destination peers 
eventually,
+altough the performance of a lookup is expected to decrease. Also, we except 
that
+some of the queries are lost. With this test case, we wish to get more 
information
+how big the lost rate is. 
+
+Simulation Process: 
+- Create 90 normal peers in the network (ID is in the format "peer1 -peer90")
+- Create 10 "dumb" peers in the network (ID is in the format "dumb1-dumb10")
+- If necessary, the number of "dumb" peers can be changed (for more "clearer" 
+  analysic etc)
+- Create 100 data items in the network (the format is "key1-100", "value1-100")
+- Perform 100 queries randomly (random peer selection (1-100) and random query 
+  selection (1-100)) with *normal* peers
+- Try to use same code as in GISP's implementation/simulation base
+- However, for "dumb" peers perhaps we have to create own class 
+  (extends GISPXML-class) which has "dumb" methods for query 
+  forward and processing
+- Test case is performed with loop (e.g., while(true) etc)
+- Update all peers' routing information every loop pass 
+- We use org.apache.log4j package for logging information
+
+Scenario #2 (dynamic "dumb"): 
+- Same except that peers join and leave the system dynamically
+- Peers can join and leave the network at a given time (e.g., 
+  "if( bigInt % factor == something)", where bigInt is increased
+  every loop pass)   
 
 
 - A hostile peer(s) tries to drop certain packets/queries wilfully*