# Secured Real-Time Machine Communication Protocol
## 5 Implementation and Evaluation  
The SRMCP is implemented in the Go programming language, with the repository available at the SRMCP Go Repository ([[https://github.com/ulfaric/srmcp](https://github.com/ulfaric/srmcp)]([https://github.com/ulfaric/srmcp](https://github.com/ulfaric/srmcp)), accessed on 5 December 2024). The Go programming language was chosen for its flexibility in creating concurrent subroutines, which SRMCP heavily depends on for transaction handling and concurrent messaging.  
Compared to other protocols in terms of security, SRMCP stands out due to its use of Kyber KEM (implemented via Cloudflare CIRCL) ([[https://github.com/cloudflare/circl](https://github.com/cloudflare/circl)]([https://github.com/cloudflare/circl](https://github.com/cloudflare/circl)), accessed on 5 December 2024) and the combination of symmetric and asymmetric encryption. Since other protocols do not incorporate any quantum-safe encryption methods, the evaluation of SRMCP focuses on performance, particularly the overhead that multi-layer encryption may cause in bursts of short operations, such as reading a single node/register. ModBus and the OPC UA are chosen as competitors since the former is widely adopted and offers the most simple communication procedures and packet structure but does not support built-in encryption; the latter is gaining popularity and supports encryption but utilizes complex communication procedures and packet structure. Consequently, a Modbus client is implemented in Go, and an OPC UA client is implemented with the Python-based open-source library \"asyncua\". A server is created to run Modbus, the OPC UA, and SRMCP simultaneously, with a series of Modbus registers pre-defined and then converted to nodes in OPC UA and SRMCP. With the clients, a series of operations are performed, including initializing the connection with the server and reading/writing operations. The completion time of each operation is collected in milliseconds. The server is placed in three scenarios:  
**Local Placement**: The server operates as a container on the same physical host where the clients reside. In this scenario, communication between the client and server occurs through the local loopback interface, which introduces minimal latency. This setup allows for precise measurement of the computational delay associated with each protocol.
2. **Local Network Placement**: The server is hosted on a separate physical machine within the same local network. This configuration is typical in air-gapped OT networks, where security and isolation from external networks are prioritized. This scenario is used to test whether SRMCP can achieve acceptable performance with generic hardware in an OT network environment.
3. **VPN over an Internet Placement-Remote Network**: The server is hosted on a separate physical machine located on a remote network, both geographically and logically distant. Connectivity to this remote network is established via a VPN over the Internet. This scenario is common in Industry 4.0 environments, where sensor readings may be streamed to cloud platforms or remote operations are performed. This scenario is to test if the performance difference between the three protocols will be diluted due to the dynamic nature of internet traffic.