[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 08:19:18

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

Log message:
        twid

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/storm/storm/doc/pegboard/attacking_gisp--hemppah/peg.rst.diff?tr1=1.15&tr2=1.16&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.15 
storm/doc/pegboard/attacking_gisp--hemppah/peg.rst:1.16
--- storm/doc/pegboard/attacking_gisp--hemppah/peg.rst:1.15     Tue Jun 10 
06:49:36 2003
+++ storm/doc/pegboard/attacking_gisp--hemppah/peg.rst  Tue Jun 10 08:19:18 2003
@@ -5,8 +5,8 @@
 
 :Authors:  Hermanni Hyytiälä
 :Date-Created: 2003-06-05
-:Last-Modified: $Date: 2003/06/10 10:49:36 $
-:Revision: $Revision: 1.15 $
+:Last-Modified: $Date: 2003/06/10 12:19:18 $
+:Revision: $Revision: 1.16 $
 :Status:   Incomplete
 
 .. :Stakeholders:
@@ -78,25 +78,26 @@
 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. 
+altough the performance of a lookup is expected to decrease (Chord's fault 
tolerant
+properties). 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 (Chord's fault tolerant 
properties). 
 
 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
+- If necessary, the number of total peers and "dumb" peers can be 
increased/decreased
+  (for "clearer" analysic etc)
+- Create 5000 key/value items in the network (the format is "key1-100", 
"value1-100")
+- Perform 2500 queries randomly with *normal* peers (random peer selection 
(peer1-100) 
+  and random query selection (key1-100))
 - Try to use same code as in GISP's implementation/simulation base
-- However, for "dumb" peers perhaps we have to create own class 
+- For "dumb" peers 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
+- Update all peers' routing information every loop pass
+- "distributed" peermap is based on Java's HashMap data structure 
(synchronized)
+- Use org.apache.log4j package for logging information
 
 Scenario #2 (dynamic "dumb"): 
 - Same except that peers join and leave the system dynamically