-
Notifications
You must be signed in to change notification settings - Fork 2
Complex encounter tests
We use the word complex to label the following test scenarios.
Basic encounter tests establish a connection once and exchange a message. We need to test system behaviour when a) peer connect and disconnect and b) if routing works as planned).
Their are options to test ASAP routing features. First - an chain of peer is established. A peer on one end of the chain sends a message that is to be received by on the other side of the chain. What would be a useful chain length? Two is already covered by or basic test. Minimum would be three. In that case, there would be just on intermediate peer. Let's introduce a second intermediate peer o be on the safe side.
X shall stand for the number of involved peers. Let's start with 4. In shorthand, that would be one basic chain scenario: Cab;Cbc;Ccd;Sa:1;Eb:1;Ec:1;Ed:1 Peer A connects B, B connects C, C connects D, A sends a message that reaches B,C and finally D.
Let's name this scenario complex:chain4
Ship locks shall prevent a ship from sinking when it is hit - let's say - by an iceberg. Works perfectly as we all know also thanks to Leonardo DiCaprio :)
Lock through describes the process to go from one part to another by closing each lock after passing through. We run that lock through scenarion with ASAP: Sa:1;Cab;Dab;Cbc;Dbc;Ccd;Dcd;Eb:1;Ec:1;Ed:1
Apparently, our script generator needs to give the system time to do something between a sequence of connects and disconnects. More specifically: Cab;Dab - There is always an implicit Wa; We could also define that any C is followed by a wait period... not a topic of that page, though.
We could mix those variants - message could partly be locked through, whereas parts of the chain are connected. We do not yet make alpha tests on that configuration.
There is at least an intermediate peer in a chain with a length of at least three. Chain test assure that routing in one direction works. Let's assure that a intermediate peer can route message to more than one peer.
X shall stand for the number of involved peers. Three is again the minimum number of a reasonable star. Let's start with 4.
In shorthand, that is the four star scenario: Cab;Cbc;Cbd;Sa:1;Sd:2;Eb:1;Ec:1;Ed:1;Ea:2;Eb:2;Ec:2 Peer A connects B, B connects C and D. B becomes the centre of the little infrastructure. A and D send messages. We expect all peers to receive them.
There are variants; A and B could send message before connections are established. That feature is already tested in the basic tests, though. Let's stick only to that variant until we face problems.
Gossip functionality is tested. Connection can come an go - the systems works as expected.
We do not bring the no-gossiping features on an aplha level in version 1.0, though.
We run all tests with a message length of 1kBytes.
Basic tests already cover message exchange between peers on different machines connetced over different networks. Let's reduce the tests efforts. We run alpha tests on Chain4
- all peers running on the same machine (for Windows, Ubuntu and Mac)
- peers running in the same network - with a mix of Windows and Ubuntu: intermediate peers run on different OS, so are first an last peer in the chain.
Same configuration as in Chain4.
Same configuration as in Chain4.
todo: switching gossip features is essential.
| Scenario | #Peers | Message | Action Sequence | Expected Result | Scripts |
|---|---|---|---|---|---|
| CoreA1_Dis | 2 | char | Core_A1; A disconnects from B; Core_A1. | B received 2 messages | v1 |
The action sequences of the integrated core scenarios will be referred to by the names of the scenarios.
| Scenario # | Peer Count | Message | Action Sequence | Expected Result | PeerA | PeerB |
|---|---|---|---|---|---|---|
| CoreA1_Dis | 2 | char |
Core_A1, A disconnects from B, Core_A1. |
B receives the message. | wait 6000 connectTCP localhost 4444 wait 6000 sendMessage TCPChain_CoreA1 sn/characters closeEncounter 1 wait 3000 wait 6000 connectTCP localhost 4444 wait 6000 sendMessage TCPChain_CoreA1 sn/characters wait 5000 lsMessages exit |
openTCP 4444 wait 36000 wait 5000 lsMessages exit |
| CoreA2-Dis | 2 | char |
Core_A2, B disconnects from A, Core_A2. |
A receives the message. | openTCP 4444 wait 36000 wait 5000 lsMessages exit |
wait 6000 connectTCP localhost 4444 wait 6000 sendMessage TCPChain_CoreA2 sn/characters closeEncounter 1 wait 3000 wait 6000 connectTCP localhost 4444 wait 6000 sendMessage TCPChain_CoreA2 sn/characters wait 5000 lsMessages exit |
| CoreB1-Dis | 2 | char |
Core_B1, A disconnects from B, Core_B1. |
B receives the message. | wait 2000 sendMessage TCPChain_CoreB1 sn/characters wait 6000 connectTCP FILLER_IP 4444 closeEncounter 1 wait 6000 wait 2000 sendMessage TCPChain_CoreB1 sn/characters wait 6000 connectTCP FILLER_IP 4444 wait 6000 wait 5000 lsMessages exit |
openTCP 4444 wait 36000 wait 5000 lsMessages exit |
| CoreB2-Dis | 2 | char |
Core_B2, B disconnects from A, Core_B2. |
A receives the message. | openTCP 4444 wait 36000 wait 5000 lsMessages exit |
wait 2000 sendMessage TCPChain_CoreB2 sn/characters wait 6000 connectTCP localhost 4444 closeEncounter 1 wait 6000 wait 2000 sendMessage TCPChain_CoreB2 sn/characters wait 6000 connectTCP localhost 4444 wait 6000 wait 5000 lsMessages exit |
| A <-> B | B <-> C | Result | Environment | |
|---|---|---|---|---|
| TC001 | CoreA1 | CoreA1 | ||
| TC002 | CoreA1 | CoreA2 | ||
| TC003 | CoreA2 | CoreA1 | ||
| TC004 | CoreA2 | CoreA2 | ||
| TC005 | CoreA1 | CoreB1 | ||
| TC006 | CoreA1 | CoreB2 | ||
| TC007 | CoreA2 | CoreB1 | ||
| TC008 | CoreA2 | CoreB2 | ||
| TC009 | CoreB1 | CoreA1 | ||
| TC010 | CoreB1 | CoreA2 | ||
| TC011 | CoreB2 | CoreA1 | ||
| TC012 | CoreB2 | CoreA2 | ||
| TC013 | CoreB1 | CoreB1 | ||
| TC014 | CoreB1 | CoreB2 | ||
| TC015 | CoreB2 | CoreB1 | ||
| TC016 | CoreB2 | CoreB2 | ||
| TC017 | CoreA1 | CoreA1_Dis | ||
| TC018 | CoreA1 | CoreA2_Dis | ||
| TC019 | CoreA1 | CoreB1_Dis | ||
| TC020 | CoreA1 | CoreB2_Dis | ||
| TC021 | CoreA2 | CoreA1_Dis | ||
| TC022 | CoreA2 | CoreA2_Dis | ||
| TC023 | CoreA2 | CoreB1_Dis | ||
| TC024 | CoreA2 | CoreB2_Dis | ||
| TC025 | CoreA1_Dis | CoreA1 | ||
| TC026 | CoreA1_Dis | CoreA2 | ||
| TC027 | CoreA1_Dis | CoreB1 | ||
| TC028 | CoreA1_Dis | CoreB2 | ||
| TC029 | CoreA2_Dis | CoreA1 | ||
| TC030 | CoreA2_Dis | CoreA2 | ||
| TC031 | CoreA2_Dis | CoreB1 | ||
| TC032 | CoreA2_Dis | CoreB2 | ||
| TC033 | CoreA1_Dis | CoreA1_Dis | ||
| TC034 | CoreA1_Dis | CoreA2_Dis | ||
| TC035 | CoreA1_Dis | CoreB1_Dis | ||
| TC036 | CoreA1_Dis | CoreB2_Dis | ||
| TC037 | CoreA2_Dis | CoreA1_Dis | ||
| TC038 | CoreA2_Dis | CoreA2_Dis | ||
| TC039 | CoreA2_Dis | CoreB1_Dis | ||
| TC040 | CoreA2_Dis | CoreB2_Dis |
- Project goals
- Step 0: Concept
- Step 1: API
- Step 2: Implementation
- Step 3: Shark Component
- Step 4: Testing
- Step 5: GUI
- Javadoc
- Shark Messenger User Guide
- How to use
- Command Page
- Basic peer management
- Managing persons
- Managing Certificates (PKI)
- De/Encrypting external files
- TCP connection handling
- Messaging
- Hub management
- Hub access management
- Encounter management
- Orchestrated Test Support