## 4 Experimental Results
### Telemetry Message Recovery  
This experimental evaluation aims to analyze the sidecar object's behavior in case of connection faults occurring at runtime using different types of recovery policies. The experiment configuration is the following: (i) 1 full message processing chain (from smart object to the cloud); (ii) 600 messages sent; (iii) Payload message size of 4 KB and (iv) a keep-alive time of 14 s (keep-alive is the maximum time from the last interaction with the server, after which the MQTT client defines the connection lost). Messages are sent at the fixed rate (600 messages @ 5 msg/s) with the following schedule (depicted in Figure 9):  
* 0:00: all systems running normally with internet connectivity;
* 0:30: the testing machine is disconnected from the WiFi network and internet;
* 1:30: the testing machine is reconnected to the same WiFi network and to internet;
* 2:00: the test ends.  
This test typology is repeated for each of the three Recovery Policy described in the Implementation chapter. The first case analyzed concerns to the NoRecovery policy, that discards all the messages received by the Publisher while in RECOVERY MODE. The results are shown in Figure 10a. It can be observed that at 0:30, in concurrence with the network disconnection, the outbound queue size starts to increase. Around 1:00 the sidecar object detects the connection loss and applies the NoRecovery policy. All the outbound messages are discarded, and any new incoming message is consequently discarded and lost. Around 1:40 connection is reestablished and new messages are published normally.  
The second analyzed case is the one relative to the AllRecovery policy, that keeps in memory all the messages received during RECOVERY MODE and restores them on top of the publishing queue during the RECOVERING phase. The results are shown in Figure 10b-d. Obtained results show that at 0:30, in concurrence with the network disconnection, the outbound queue size started to increase. Around 1:00 the sidecar object detected the connection loss and applied the AllRecovery policy: all the outbound messages were transferred to the RecoveryHandler queue, and any new message coming from the smart object was forwarded to the same queue. At around 1:45 connection was reestablished: messages contained in the recovery queue were sent back to the publisher, which took around 3 s to handle and recover all the collected messages before returning to the normal behavior.  
The third case analyzed is the one relative to the OneEveryNRecovery policy, which keeps in memory only one message every N received during RECOVERY MODE (for this test, N = 5) while discarding the others. The results are shown in Figure 10e-g. It can be observed that at 0:30, in concurrence with the network disconnection, the Outbound Queue size starts to increase. Around 1:00, the sidecar object detected the connection loss and applies the OneEveryNRecovery policy: only one message every 5 is transferred to the RecoveryHandler queue, and any new message coming from the smart object follow the same procedure. At around 1:45, connection was reestablished: messages contained in the recovery queue were sent back to the publisher, which this time took only 0.5 s to deal with the restored messages before returning to the normal behavior.  
Figure 9: Recovery tests timeline.  
Starting from the performed and presented evaluation emerges how the Recovery Policy significantly influences the behavior of the sidecar object, highlighting the importance of choosing the right policy depending on the needs specific of each use case and application scenario.