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 |
|
|
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 |