[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 09:10:34

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.16&tr2=1.17&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.16 
storm/doc/pegboard/attacking_gisp--hemppah/peg.rst:1.17
--- storm/doc/pegboard/attacking_gisp--hemppah/peg.rst:1.16     Tue Jun 10 
08:19:18 2003
+++ storm/doc/pegboard/attacking_gisp--hemppah/peg.rst  Tue Jun 10 09:10:33 2003
@@ -1,12 +1,11 @@
-
 ==========================================================================
 PEG attacking_gisp--hemppah:
 ==========================================================================
 
 :Authors:  Hermanni Hyytiälä
 :Date-Created: 2003-06-05
-:Last-Modified: $Date: 2003/06/10 12:19:18 $
-:Revision: $Revision: 1.16 $
+:Last-Modified: $Date: 2003/06/10 13:10:33 $
+:Revision: $Revision: 1.17 $
 :Status:   Incomplete
 
 .. :Stakeholders:
@@ -16,7 +15,7 @@
 .. Affect-PEGs:
 
 This PEG document briefly describes the attack methods used by a "killer" 
-program. The program is intended to be used to test GISP P2P software's 
+program. The program is intended to be used to test GISP_ P2P software's 
 robustness against hostile attacks.  
 
 In this document we mean with "hostile peer" as an entity which is able to do 
a 
@@ -77,26 +76,41 @@
 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 (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). 
+We expect that GISP's fault tolerance is at least at the same level as 
Chord_'s 
+fault tolerace since GISP's routing table is based on Chord's routing table:
+
+.. place here some results from the Chord paper
+
+Thus, 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.
+
+Eventually, we will compare (and validate) our test results with the Chord's 
+fault tolerance 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 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))
+  
+    .. list different settings...
+  
+- Create 5000 key/value items in the network (the format is "key1-5000", 
"value1-5000")
+- Perform 2500 queries randomly with *normal* peers (random peer selection 
(peer1-5000) 
+  and random query selection (key1-5000))
 - Try to use same code as in GISP's implementation/simulation base
 - 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
-- "distributed" peermap is based on Java's HashMap data structure 
(synchronized)
+
+.. Then you need to run until you've reached a steady state, and have an 
estimate
+   of how long that will take beforehand, and also about what the steady
+   state will be like.
+   
+- "Distributed" peermap is based on Java's HashMap data structure 
(synchronized)
 - Use org.apache.log4j package for logging information
 
 Scenario #2 (dynamic "dumb"): 
@@ -148,3 +162,5 @@
 
 .. _ref1: http://www.cs.rice.edu/Conferences/IPTPS02/173.pdf    
 .. _ref2: 
http://dcslab.snu.ac.kr/~buggy/p2p/paper/security/Pastry%20--%20Security%20for%20structured%20peer-to-peer%20overlay%20networks.pdf
+.. _Chord: http://www.pdos.lcs.mit.edu/chord/
+.. _GISP: http://gisp.jxta.org