|
|
|
1 |
========================================================================== |
========================================================================== |
2 |
PEG attacking_gisp--hemppah: |
PEG attacking_gisp--hemppah: |
3 |
========================================================================== |
========================================================================== |
15 |
.. Affect-PEGs: |
.. Affect-PEGs: |
16 |
|
|
17 |
This PEG document briefly describes the attack methods used by a "killer" |
This PEG document briefly describes the attack methods used by a "killer" |
18 |
program. The program is intended to be used to test GISP P2P software's |
program. The program is intended to be used to test GISP_ P2P software's |
19 |
robustness against hostile attacks. |
robustness against hostile attacks. |
20 |
|
|
21 |
In this document we mean with "hostile peer" as an entity which is able to do a |
In this document we mean with "hostile peer" as an entity which is able to do a |
76 |
the test is running. In the second variation, peers can join and leave the |
the test is running. In the second variation, peers can join and leave the |
77 |
system while the test is running. |
system while the test is running. |
78 |
|
|
79 |
We expect that GISP is able to route some queries to their destination peers eventually, |
We expect that GISP's fault tolerance is at least at the same level as Chord_'s |
80 |
altough the performance of a lookup is expected to decrease (Chord's fault tolerant |
fault tolerace since GISP's routing table is based on Chord's routing table: |
81 |
properties). Also, we except that some of the queries are lost. With this test case, we wish |
|
82 |
to get more information how big the lost rate is (Chord's fault tolerant properties). |
.. place here some results from the Chord paper |
83 |
|
|
84 |
|
Thus, we expect that GISP is able to route some queries to their destination |
85 |
|
peers eventually, altough the performance of a lookup is expected to decrease. Also, |
86 |
|
we except that some of the queries are lost. With this test case, we wish |
87 |
|
to get more information how big the lost rate is. |
88 |
|
|
89 |
|
Eventually, we will compare (and validate) our test results with the Chord's |
90 |
|
fault tolerance properties. |
91 |
|
|
92 |
Simulation Process: |
Simulation Process: |
93 |
- Create 90 normal peers in the network (ID is in the format "peer1 -peer90") |
- Create 90 normal peers in the network (ID is in the format "peer1 -peer90") |
94 |
- Create 10 "dumb" peers in the network (ID is in the format "dumb1-dumb10") |
- Create 10 "dumb" peers in the network (ID is in the format "dumb1-dumb10") |
95 |
- If necessary, the number of total peers and "dumb" peers can be increased/decreased |
- If necessary, the number of total peers and "dumb" peers can be increased/decreased |
96 |
(for "clearer" analysic etc) |
|
97 |
- Create 5000 key/value items in the network (the format is "key1-100", "value1-100") |
.. list different settings... |
98 |
- Perform 2500 queries randomly with *normal* peers (random peer selection (peer1-100) |
|
99 |
and random query selection (key1-100)) |
- Create 5000 key/value items in the network (the format is "key1-5000", "value1-5000") |
100 |
|
- Perform 2500 queries randomly with *normal* peers (random peer selection (peer1-5000) |
101 |
|
and random query selection (key1-5000)) |
102 |
- Try to use same code as in GISP's implementation/simulation base |
- Try to use same code as in GISP's implementation/simulation base |
103 |
- For "dumb" peers we have to create own class |
- For "dumb" peers we have to create own class |
104 |
(extends GISPXML-class) which has "dumb" methods for query |
(extends GISPXML-class) which has "dumb" methods for query |
105 |
forward and processing |
forward and processing |
106 |
- Test case is performed with loop (e.g., while(true) etc) |
- Test case is performed with loop (e.g., while(true) etc) |
107 |
- Update all peers' routing information every loop pass |
- Update all peers' routing information every loop pass |
108 |
- "distributed" peermap is based on Java's HashMap data structure (synchronized) |
|
109 |
|
.. Then you need to run until you've reached a steady state, and have an estimate |
110 |
|
of how long that will take beforehand, and also about what the steady |
111 |
|
state will be like. |
112 |
|
|
113 |
|
- "Distributed" peermap is based on Java's HashMap data structure (synchronized) |
114 |
- Use org.apache.log4j package for logging information |
- Use org.apache.log4j package for logging information |
115 |
|
|
116 |
Scenario #2 (dynamic "dumb"): |
Scenario #2 (dynamic "dumb"): |
162 |
|
|
163 |
.. _ref1: http://www.cs.rice.edu/Conferences/IPTPS02/173.pdf |
.. _ref1: http://www.cs.rice.edu/Conferences/IPTPS02/173.pdf |
164 |
.. _ref2: http://dcslab.snu.ac.kr/~buggy/p2p/paper/security/Pastry%20--%20Security%20for%20structured%20peer-to-peer%20overlay%20networks.pdf |
.. _ref2: http://dcslab.snu.ac.kr/~buggy/p2p/paper/security/Pastry%20--%20Security%20for%20structured%20peer-to-peer%20overlay%20networks.pdf |
165 |
|
.. _Chord: http://www.pdos.lcs.mit.edu/chord/ |
166 |
|
.. _GISP: http://gisp.jxta.org |