/[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.40 by hemppah, Tue Jun 17 08:01:45 2003 UTC revision 1.41 by hemppah, Fri Aug 1 12:01:07 2003 UTC
# Line 140  We expect that GISP's fault tolerance is Line 140  We expect that GISP's fault tolerance is
140  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.
141    
142  Chord's general properties:  Chord's general properties:
143  - O(log^2 n) messages are required to join/leave operations  
144    - O(log^2 n) messages are required to join/leave operations
145    
146  - O(log n) lookup efficiency  - O(log n) lookup efficiency
147    
148  - Routing table maintains information about O(log n) peers  - Routing table maintains information about O(log n) peers
149    
150  - Routing table requires information about O(log n) of other peers  - Routing table requires information about O(log n) of other peers
151    of *efficient* routing, but performance degrades gracefully    of efficient routing, but performance degrades gracefully
152    when that information is out of date    when that information is out of date
153      
154  - Only one piece of information per peer need to be corect in  - Only one piece of information per peer need to be corect in
155    order to guarantee correct (though slow) routing queries      order to guarantee correct (though slow) routing queries
156      
157  - Requires active stabilization protocol to aggressively maintain  - Requires active stabilization protocol to aggressively maintain
158    the routing tables of all peers    the routing tables of all peers
159      
160  - "As long as the the time fo adjust incorrect routing table entries  - "As long as the the time fo adjust incorrect routing table entries
161    is less than the time it takes to the network to double in size,    is less than the time it takes to the network to double in size,
162    lookups should continue to take O(log n)"    lookups should continue to take O(log n)"
163      
164  - Has no specific mechanism to heal partitioned peer groups  - Has no specific mechanism to heal partitioned peer groups
165    
166  - Additional redundancy can be achievied using a "successor-list",  - Additional redundancy can be achievied using a "successor-list",
167    e.g., O(log n) successor peers    e.g., O(log n) successor peers
168      
169  - Numerial metric: no "peer-choice" during lookups  - Numerial metric: no "peer-choice" during lookups
170    
171  Additionally, the current version of GISP (3.4) have following properties:  Additionally, the current version of GISP (3.4) have following properties:
172  - Only uses the idea of XOR-metric in Kademlia.  
173    - Only uses the idea of XOR-metric in Kademlia
174    
175  - The protocol specification of GISP-3.4 allows the "free choice", *but*  - The protocol specification of GISP-3.4 allows the "free choice", *but*
176    the current Java implementation just selects fixed peers (like Chord)    the current Java implementation just selects fixed peers (like Chord)
177      
178  - Compared to Chord routing table, GISP-3.4 protocol specification  - Compared to Chord routing table, GISP-3.4 protocol specification
179    suggests peers to cache as much peer information as possible    suggests peers to cache as much peer information as possible
180    (in order to reduce hops)    (in order to reduce hops)
181      
182  - The current implementation does not support "free choice"  - The current implementation does not support "free choice"
183    
184  - Future versions may include "peer strength" feature (a peer decides  - Future versions may include "peer strength" feature (a peer decides
185    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)
186      
187  - GISP maintains cache information about 10000 peers (max) whereas Chord  - GISP maintains cache information about 10000 peers (max) whereas Chord
188    caches information about 1000 peers (max)    caches information about 1000 peers (max)
189        
# Line 193  Simultaneous peer failures: Line 209  Simultaneous peer failures:
209  - No peers join or leave the system  - No peers join or leave the system
210  - Result: 20% of lookups fail, when 20% of peers are failed  - Result: 20% of lookups fail, when 20% of peers are failed
211    
212  Lookups during peers join and leave the system:  Lookups during peers join and leave the system:
213    
214  - The fraction of lookups fail as a function of the rate (over time)  - The fraction of lookups fail as a function of the rate (over time)
215    at which peers join and leave the system    at which peers join and leave the system
216      
217  - Only failures caused by Chord state inconsistency are included, not  - Only failures caused by Chord state inconsistency are included, not
218    failures due to lost keys (text copied directly from the figure text)    failures due to lost keys (text copied directly from the figure text)
219      
220  - The authors  - The authors
221    
222  - Queries are not retried  - Queries are not retried
223    
224  - 500 peers  - 500 peers
225    
226  - Result: 6.5% of lookups fail, when peer join/leave rate per second  - Result: 6.5% of lookups fail, when peer join/leave rate per second
227    is 0.1 (corresponds to peer joining and leaving every 10 seconds    is 0.1 (corresponds to peer joining and leaving every 10 seconds
228    on average)    on average)
229        
230    
231  Simulation Process:  Simulation Process:
232    
233  - Fraction of "dumb" peers is constant: create 9*10^k normal peers,  - Fraction of "dumb" peers is constant: create 9*10^k normal peers,
234    create 1*10^k "dumb" peers, where k = 1..3    create 1*10^k "dumb" peers, where k = 1..3
235      
236  - Fraction of "dumb" peers is dynamic: create n*10^k normal peers,  - Fraction of "dumb" peers is dynamic: create n*10^k normal peers,
237    d*10^k "dumb" peers, where k = 1..3, n = 1..9 and d = 1..9    d*10^k "dumb" peers, where k = 1..3, n = 1..9 and d = 1..9
238      
239  - Use both the constant and dynamic fraction scenarios, start with the  - Use both the constant and dynamic fraction scenarios, start with the
240    constant    constant
241  - Create 100*N key/value items in the network, where the N is the number of all peers in the network    
242    - Create 100*N key/value items in the network, where the N is the number of
243      all peers in the network
244    
245  - Each peer queries a set of random keys  - Each peer queries a set of random keys
246    
247  - Try to use same code as in GISP's implementation/simulation base  - Try to use same code as in GISP's implementation/simulation base
248    
249  - For "dumb" peers we have to create own class  - For "dumb" peers we have to create own class
250    (extends GISPXML-class) which has "dumb" methods for query    (extends GISPXML-class) which has "dumb" methods for query
251    forward and processing    forward and processing

Legend:
Removed from v.1.40  
changed lines
  Added in v.1.41

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