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