[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/11 08:03:13

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

Log message:
        update

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/storm/storm/doc/pegboard/attacking_gisp--hemppah/peg.rst.diff?tr1=1.22&tr2=1.23&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.22 
storm/doc/pegboard/attacking_gisp--hemppah/peg.rst:1.23
--- storm/doc/pegboard/attacking_gisp--hemppah/peg.rst:1.22     Wed Jun 11 
07:02:03 2003
+++ storm/doc/pegboard/attacking_gisp--hemppah/peg.rst  Wed Jun 11 08:03:12 2003
@@ -4,8 +4,8 @@
 
 :Authors:  Hermanni Hyytiälä
 :Date-Created: 2003-06-05
-:Last-Modified: $Date: 2003/06/11 11:02:03 $
-:Revision: $Revision: 1.22 $
+:Last-Modified: $Date: 2003/06/11 12:03:12 $
+:Revision: $Revision: 1.23 $
 :Status:   Incomplete
 
 .. :Stakeholders:
@@ -14,9 +14,9 @@
 
 .. 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 
-robustness against hostile attacks.  
+This is the first version of PEG document which briefly describes the attack 
+methods used by a "killer" 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 
 (limited/simplified/modified) number of regular GISP peer's functionalies
@@ -24,13 +24,15 @@
 and redundancy. The harmfulness of a peer is a consequence of the fact
 that a peer is wilfully malicious. 
 
+Once this PEG is accepted we will start the experiments.
+
 Disclaimer
 ==========
 This program is only used for research purposes and
 the goal is to improve GISP's resilience against hostile attacks.
 
 Additionally, the author of GISP has stated that he will address 
-attacks as they become a problem. This inclines to think 
+attacks as they become a problem. This inclines us to think 
 that writing an attack program will get the author to address 
 that attacks.
 
@@ -137,47 +139,21 @@
 fault tolerance properties.
 
 Simulation Process: 
-- 9*10^k normal peers, 1*10^k "dumb" peers, where k = 1..3
-- n*10^k normal peers, d*10^k "dumb" peers, where k = 1..3, n = 1..9
-  and d = 1..9
-- For a normal peers ID is in the format "peer1, peer2..." and for a "dumb" 
peer 
-  ID is in the format "dumb1, dumb2..." 
-- Create 5000 key/value items in the network (the format is "key1, key2...", 
-  "value1, value2...")
-- Perform 2500 queries randomly with *normal* peers (random peer selection  
-  and random query selection)
+- Fraction of "dumb" peers is constant: create 9*10^k normal peers, 
+  create 1*10^k "dumb" peers, where k = 1..3
+- Fraction of "dumb" peers is dynamic: create n*10^k normal peers, 
+  d*10^k "dumb" peers, where k = 1..3, n = 1..9 and d = 1..9
+- Use both the constant and dynamic fraction scenarios, start with the
+  constant  
+- For a normal peers ID is in the format "peer1, peer2..." and for a 
+  "dumb" peer ID is in the format "dumb1, dumb2..." 
+- Create 100*N key/value items in the network (the format is "key1, key2...", 
+  "value1, value2..."), where the N is the number of all peers in the network
+- Each peer queries a set of random keys
 - 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)
-- 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*
-  
-- A hostile peer(s) forwards queries to incorrect destination peers
-
-- A hostile peer(s) gives false information during queries
-
-- A hostile peer(s)'s queries/replies include loads of rubbish, i.e., 
-  wrong XML-scheme, wrong string/text encoding, or doesn't otherwise follow 
the protocol
-  
-- A hostile peer(s) performs many queries randomly
-
-- A hostile peer(s) performs many queries wilfully with a certain key
-
-- A hostile peer(s) stores lot of dummy random key-value-pairs
-
-- A hostile peer(s) stores lot of dummy key-value-pairs with a certain key
 
 During the simulation process we will use a single hostile  peer
 or a group of hostile peers (fraction of all peers) in the test network.
@@ -195,7 +171,7 @@
 
 ISSUE: Does GISP support "peer-choice" during lookups?
 
-ISSUE: Does GISP peer is able determine if an another peer is
+ISSUE: Is GISP peer able to determine if an another peer is
        not "useful" or not (not just PING scenario)  ("a peer can discard
        information of unreachable peers")