/[storm]/storm/doc/pegboard/attacking_gisp--hemppah/peg.rst
ViewVC logotype

Diff of /storm/doc/pegboard/attacking_gisp--hemppah/peg.rst

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.17 by hemppah, Tue Jun 10 13:10:33 2003 UTC revision 1.18 by hemppah, Wed Jun 11 08:10:25 2003 UTC
# Line 77  the test is running. In the second varia Line 77  the test is running. In the second varia
77  system while the test is running.  system while the test is running.
78    
79  We expect that GISP's fault tolerance is at least at the same level as Chord_'s  We expect that GISP's fault tolerance is at least at the same level as Chord_'s
80  fault tolerace since GISP's routing table is based on Chord's routing table:  fault tolerace since GISP's routing table is based on Chord's routing table.
81    
82  .. place here some results from the Chord paper  Chord's general properties:
83    - O(log^2 n) messages are required to join/leave operations
84    - O(log n) lookup efficiency
85    - Routing table maintains information about O(log n) peers
86    - Requires active stabilization protocol to aggressively maintain
87      the routing tables of all peers
88    - Has no specific mechanism to heal partitioned peer groups
89    
90    The assumption for the results above is that the system is "in the steady state",
91    according to the authors.
92    
93    Note: The length of the path to resolve the query is O(log n) *with high
94    probability*.  
95    
96    Example Chord's path lengths in a static network (from figure):
97    
98    ~10 peers: 2 (average)
99    ~20 peers: 2 (average)
100    ~100 peers: 3 (average)
101    ~1000 peers: 5 (average)
102    ~10000 peers: 6 (average)
103    ~16000 peers: 7 (average)
104    
105    Chord's fault tolerance properties include (from the figures):
106    
107    Simultaneous peer failures:
108    - Randomly selected fraction of nodes fail
109    - No peers join or leave the system
110    - Result: 20% of lookups fail, when 20% of peers are failed
111    
112    Lookups during peers join and leave the system:
113    - The fraction of lookups fail as a function of the rate (over time)
114      at which peers join and leave the system
115    - Only failures caused by Chord state inconsistency are included, not
116      failures due to lost keys (text copied directly from the figure text)
117    - The authors
118    - Queries are not retried
119    - 500 peers
120    - Result: 6.5% of lookups fail, when peer join/leave rate per second
121      is 0.1 (corresponds to peer joining and leaving every 10 seconds
122      on average)
123    
 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.  
124    
125  Eventually, we will compare (and validate) our test results with the Chord's  Eventually, we will compare (and validate) our test results with the Chord's
126  fault tolerance properties.  fault tolerance properties.
127    
128  Simulation Process:  Simulation Process:
129  - Create 90 normal peers in the network (ID is in the format "peer1 -peer90")  - 9*10^k normal peers, 1*10^k "dumb" peers, where k = 1..3
130  - Create 10 "dumb" peers in the network (ID is in the format "dumb1-dumb10")  - n*10^k normal peers, d*10^k "dumb" peers, where k = 1..3, n = 1..9
131  - If necessary, the number of total peers and "dumb" peers can be increased/decreased    and d = 1..9
132      - For a normal peers ID is in the format "peer1, peer2..." and for a "dumb" peer
133      .. list different settings...    ID is in the format "dumb1, dumb2..."
134      - Create 5000 key/value items in the network (the format is "key1, key2...",
135  - Create 5000 key/value items in the network (the format is "key1-5000", "value1-5000")    "value1, value2...")
136  - Perform 2500 queries randomly with *normal* peers (random peer selection (peer1-5000)  - Perform 2500 queries randomly with *normal* peers (random peer selection  
137    and random query selection (key1-5000))    and random query selection)
138  - Try to use same code as in GISP's implementation/simulation base  - Try to use same code as in GISP's implementation/simulation base
139  - For "dumb" peers we have to create own class  - For "dumb" peers we have to create own class
140    (extends GISPXML-class) which has "dumb" methods for query    (extends GISPXML-class) which has "dumb" methods for query
141    forward and processing    forward and processing
142  - Test case is performed with loop (e.g., while(true) etc)  - Test case is performed with loop (e.g., while(true) etc)
143  - Update all peers' routing information every loop pass  - Update all peers' routing information every loop pass
   
 .. 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.  
     
144  - "Distributed" peermap is based on Java's HashMap data structure (synchronized)  - "Distributed" peermap is based on Java's HashMap data structure (synchronized)
145  - Use org.apache.log4j package for logging information  - Use org.apache.log4j package for logging information
146    

Legend:
Removed from v.1.17  
changed lines
  Added in v.1.18

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26