Hub encounter tests

We use the word Hub to label hub specific additional test builing blocks.

• Hub test structure
• Scenarios
• Hub test building blocks
• Alpha Tested Features

A few words on hub and SNM default behaviour

A hub is an infrastructure element. It accepts TCP connections. A hub is part of each SharkNetMessenger distribution.

Simplest way to start a hub is this CLI command: startHub. A hub is running in its own thread, listening on port 6907.

Simplest way to connect a peer to a hub is using this CLI command: connnectHub. A more specific version - with the same result - would be connectHub localhost 6907

Peer and hub run the hub protocol. Even developers will hardly get directly in contact with this protocol. A peer provides its ID. The hub will provide a list of peers currently connected.

SNM follows a hard-coded behaviour: That list of peers of provided to the encounter manager. It will in turn ask the hub to establish a connection to each peer to which no other connection exists.

CLI command lsConnectedHubs provides a list of connected hubs including connected peers. lsEncounters provides a list of encounter(s) (running and in the past). SNM remembers each hub and will try to reconnect during re-start.

SNM also asks frequently for a fresh list of peers connected to each hub. Encounter manager will decide whether to establish a new ASAP session or not. If so, a ASAP session starts. Data run from a peer to the hub and will be forwarded to the other peer. Yes, a hub is a perfect place for eavesdropping and worse. Our implementation does not do such a thing - check the code.

Here is a very relevant detail: What TCP connection is used to run this hub mediated ASAP encounter?

new connection or not

Each peers has already got a TCP with a hub. It is used to run the hub protocol. What happens when a peer wants to run a hub mediated ASAP session, though? More specifically: What TCP connection is used?

There are two options:

• A new connection between hub and peer will be established
• Hub protocol is suspended. The existing TCP connection is used.

Users will hardly recognise the difference. In Internet scenarios, a new connection is the best choice. We introduced the second option the support especially LoRaWan based applications. Details are not relevant here. That option exists for good reason and it must be tested.

Establishing a new connection is default behaviour. It can be changed on both sides, hub and SNM. On the CLI, explicitly set the new connection parameter to false, like e.g. connectHub localhost 6907 false

There is one recognisable effect, though: Peer can disconnect from a hub (disconnectHub). An ASAP encounter won't be terminated if a new connection was established. An ASAP encounter will be terminated if the existing TCP connection was used.

Hub test structure

Each hub test comprises at least three threads/processes: Hub and at least two peers. A hub can run with default behaviour and establish new connection. The other options must be tested as well. We have always two test versions - create a new connection or not.

General test structure is straight forward:

• Start a hub (option new connection true or false)
• At least two peers connect to a hub
• Run encounter tests. Better all of them.

We have two additional test building blocks here: Start hub and connect to hub. The actual tests are already described in our (basic and complex) encounter tests.

Hub test building blocks

start a hub

Scenario #	Action	Expected Result	Commands
HT	Hub is started	Hub running	startHub <port> true
HF	Hub is started	Hub running	startHub <port> false
HStop	Hub is started	Hub running	stopHub <port>

connect to hub

Scenario #	Action	Expected Result	Commands
HCTa	Peer A connects hub	A is connected to hub	connectHub <ip-address> <port> true
HCFa	Peer A connects hub	A is connected to hub	connectHub <ip-address> <port> false

Scenarios

A hub seems to replace the intermediate peer in the star configuration. That's not true since a hub has no memory. But we could run a hub beside a full peer. That combination would act like a server. Interesting point we do not discuss here, though.

What is to be tested on the hub?

• Does connection establishment works at all?
• Does the hub maintain longer lasting connections ?
• How does the hub deal with different message length ?

HubTX_Length

T stands for true - hub is going to create a new connection as basis for an ASAP encounter. X stands for number of involved peers. We test if a hub can process different message length.

HubT3_1k would be: HT;HCTa;HCTb;HCTc;Wa;Sa:1_1k;Eb:1;Ec:1

A hub is created. Three peers connect. Peer A will send a message. It has to wait until each peer in the scenario had a chance get connected to each other. This works without user (CLI) interaction beyond the scences in the SharkNetMessenger, see above. We expect peers B and C to receive the message.

HubTStalling_X

T stands for true - hub is going to create a new connection as basis for an ASAP encounter. X stand for the time interval before a peer sends a new message. Milliseconds is assumed default unit.

HubTStalling_1000 would be: HT;HCTa;HCTb;Wa;Sa:1;Wa:1000;Sa:2;Wa:1000;Sa:3;Wa:1000;Eb:1;Eb:2;Eb:3

HubTStalling_1000 is the same as HubTStalling_1s (1s == 1000 milliseconds)

Alpha Tested Features

Version 1.0

We do Alpha tests only on the new connection == true feature on the hub. (We deal with other issues in the LoRa side. We are not in a hurry here).

HubT3 scenario is tested with medium up to very long messages. In short: Hub3_1k, Hub3_100k, Hub3_100M

HubTStalling is tested in those variants: HubTStalling_1s, HubTStalling_1min, HubTStalling_10min

Core Scenarios

Scenario #	Peer Count	Message	Action Sequence	Expected Result	PeerA	PeerB
Hub_Core1	2	-	-hubHost - Peer A connects to the Hub - Peer B connects to the Hub.	Peer A and Peer B have an encounter through the Hub.	wait 2000 connectHub localhost 6907 wait 2000 wait 1000 lsEncounter lsMessages exit	wait 500 wait 2000 connectHub localhost 6907 wait 2000 wait 1000 lsEncounter wait 500 lsMessages exit
Hub_Core2	2	-	-hubHost - Peer B connects to the Hub - Peer A connects to the Hub.	Peer A and Peer B have an encounter through the Hub.	wait 500 wait 2000 connectHub localhost 6907 wait 2000 wait 1000 lsEncounter wait 500 lsMessages exit	wait 2000 connectHub localhost 6907 wait 2000 wait 1000 lsEncounter lsMessages exit
Hub_A1	2	char	Hub_Host, Hub_Core1, Peer A sends a message	Peer B receives the message.	wait 2000 connectHub localhost 6907 wait 2000 wait 1000 lsEncounter sendMessage HUBCoreA1_ sn/characters wait 5000 lsMessages exit	wait 500 wait 2000 connectHub localhost 6907 wait 2000 wait 1000 lsEncounter wait 500 wait 5000 lsMessages exit
Hub_A2	2	char	Hub_Host, Hub_Core2, Peer B sends a message	Peer A receives the message.	wait 500 wait 2000 connectHub localhost 6907 wait 2000 wait 1000 lsEncounter wait 500 sendMessage HUBCoreA2_ sn/characters wait 5000 lsMessages exit	wait 2000 connectHub localhost 6907 wait 2000 wait 1000 lsEncounter wait 5000 lsMessages exit
Hub_B1	2	char	Hub_Host, Peer A sends a message, Hub_Core1	Peer B receives the message.	sendMessage HUBCoreB1_ sn/characters wait 2000 connectHub localhost 6907 wait 2000 wait 1000 lsEncounter wait 6000 lsMessages exit	wait 500 wait 2000 connectHub localhost 6907 wait 2000 wait 1000 lsEncounter wait 500 wait 6000 lsMessages exit
Hub_B2	2	char	Hub_Host, Peer B sends a message, Hub_Core2	Peer A receives the message.	sendMessage HUBCoreB2_ sn/characters wait 500 wait 2000 connectHub localhost 6907 wait 2000 wait 1000 lsEncounter wait 500 wait 6000 lsMessages exit	wait 2000 connectHub localhost 6907 wait 2000 wait 1000 lsEncounter wait 6000 lsMessages exit

Combined Scenarios

Scenario #	Peer Count	Message	Action Sequence	Expected Result	PeerA	PeerB
Hub_DisA1	2	char	Hub_Host, Hub_Core1, Peer B disconnects from the hub, Peer A sends a message.	Peer B receives the message.	wait 2000 connectHub localhost 6907 wait 2000 wait 1000 lsEncounter wait 6000 sendMessage HUBCoreA1_Dis_ sn/characters wait 24000 wait 5000 lsMessages exit	wait 500 wait 2000 connectHub localhost 6907 wait 2000 wait 1000y lsEncounter wait 500 disconnectHub 1 wait 24000 wait 5000 lsMessages exit
Hub_DisB1	2	char	Hub_Host, Hub_Core2, Peer A disconnects from the hub, Peer B sends a message.	Peer A receives the message.	wait 500 wait 2000 connectHub localhost 6907 wait 2000 wait 1000 lsEncounter wait 500 disconnectHub 1 wait 12000 wait 6000 lsMessages exit	wait 2000 connectHub localhost 6907 wait 2000 wait 1000 lsEncounter wait 6000 sendMessage HUBCoreB1_Dis_ sn/characters wait 6000 lsMessages exit
Hub_DisA2	2	char	Hub_Host, Hub_Core1, Peer B disconnects from the hub, Peer B sends a message.	Peer A receives the message.	wait 2000 connectHub localhost 6907 wait 2000 wait 1000 lsEncounter wait 6000 wait 5000 lsMessages exit	wait 500 wait 2000 connectHub localhost 6907 wait 2000 wait 1000 lsEncounter wait 500 disconnectHub 1 wait 12000 sendMessage HUBCoreA2_Dis_ sn/characters wait 5000 lsMessages exit
Hub_DisB2	2	char	Hub_Host, Hub_Core2, Peer A disconnects from the hub, Peer A sends a message.	Peer B receives the message.	wait 2000 connectHub FILLER_IP 6907 wait 2000 wait 1000 lsEncounter wait 6000 disconnectHub 1 wait 3000 sendMessage HUBCoreB2_Dis sn/characters wait 5000 lsMessages exit	wait 500 wait 2000 connectHub FILLER_IP 6907 wait 2000 wait 1000 lsEncounter wait 500 disconnectHub 1 wait 12000 wait 5000 lsMessages exit