[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/08/01 08:01:08

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

Log message:
        reformat

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/storm/storm/doc/pegboard/attacking_gisp--hemppah/peg.rst.diff?tr1=1.40&tr2=1.41&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.40 
storm/doc/pegboard/attacking_gisp--hemppah/peg.rst:1.41
--- storm/doc/pegboard/attacking_gisp--hemppah/peg.rst:1.40     Tue Jun 17 
04:01:45 2003
+++ storm/doc/pegboard/attacking_gisp--hemppah/peg.rst  Fri Aug  1 08:01:07 2003
@@ -4,8 +4,8 @@
 
 :Authors:  Hermanni Hyytiälä
 :Date-Created: 2003-06-05
-:Last-Modified: $Date: 2003/06/17 08:01:45 $
-:Revision: $Revision: 1.40 $
+:Last-Modified: $Date: 2003/08/01 12:01:07 $
+:Revision: $Revision: 1.41 $
 :Status:   Incomplete
 
 .. :Stakeholders:
@@ -140,34 +140,50 @@
 fault tolerace since GISP's routing table is based on Chord's routing table.
 
 Chord's general properties:
-- O(log^2 n) messages are required to join/leave operations 
+
+- O(log^2 n) messages are required to join/leave operations
+ 
 - O(log n) lookup efficiency
+
 - Routing table maintains information about O(log n) peers
+
 - Routing table requires information about O(log n) of other peers
-  of *efficient* routing, but performance degrades gracefully
-  when that information is out of date 
+  of efficient routing, but performance degrades gracefully
+  when that information is out of date
+  
 - Only one piece of information per peer need to be corect in 
-  order to guarantee correct (though slow) routing queries  
+  order to guarantee correct (though slow) routing queries
+  
 - Requires active stabilization protocol to aggressively maintain
-  the routing tables of all peers 
+  the routing tables of all peers
+  
 - "As long as the the time fo adjust incorrect routing table entries
   is less than the time it takes to the network to double in size,
   lookups should continue to take O(log n)"
+  
 - Has no specific mechanism to heal partitioned peer groups
+
 - Additional redundancy can be achievied using a "successor-list",
   e.g., O(log n) successor peers
+  
 - Numerial metric: no "peer-choice" during lookups
 
 Additionally, the current version of GISP (3.4) have following properties:
-- Only uses the idea of XOR-metric in Kademlia.
+
+- Only uses the idea of XOR-metric in Kademlia
+
 - The protocol specification of GISP-3.4 allows the "free choice", *but*
   the current Java implementation just selects fixed peers (like Chord)
+  
 - Compared to Chord routing table, GISP-3.4 protocol specification 
   suggests peers to cache as much peer information as possible
   (in order to reduce hops)
+  
 - The current implementation does not support "free choice"
+
 - Future versions may include "peer strength" feature (a peer decides 
-  whether to put it an another peer in its routing table or not)  
+  whether to put it an another peer in its routing table or not)
+  
 - GISP maintains cache information about 10000 peers (max) whereas Chord
   caches information about 1000 peers (max)
   
@@ -193,29 +209,43 @@
 - No peers join or leave the system
 - Result: 20% of lookups fail, when 20% of peers are failed
 
-Lookups during peers join and leave the system: 
+Lookups during peers join and leave the system:
+ 
 - The fraction of lookups fail as a function of the rate (over time)
   at which peers join and leave the system
+  
 - Only failures caused by Chord state inconsistency are included, not
   failures due to lost keys (text copied directly from the figure text)
+  
 - The authors
+
 - Queries are not retried
+
 - 500 peers
+
 - Result: 6.5% of lookups fail, when peer join/leave rate per second
   is 0.1 (corresponds to peer joining and leaving every 10 seconds
   on average)
   
 
-Simulation Process: 
+Simulation Process:
+ 
 - 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
-- Create 100*N key/value items in the network, where the N is the number of 
all peers in the network
+  
+- Create 100*N key/value items in the network, 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