# Secured Real-Time Machine Communication Protocol
## 3 Methodology-SRMCP Protocol Design
### Message Structure  
The message structure of SRMCP is illustrated in Figure 3, which includes three parts:  
1. **Pre-Header**: This contains a list of 8 bytes, in which the first 4 bytes represent an unsigned integer indicating the length of the header, and the last 4 bytes represent an unsigned integer indicating the length of the body.
2. **Header**: This contains fields including the message type, the unique ID of the sender, the timestamp, and the unique ID of the corresponding transaction. Optionally, the header also includes the segment index and the number of segments if port hopping is engaged.
3. **Body**: This contains the actual payload, whose content depends on the message type indicated inside the header.  
The pre-header is encrypted by TLS asymmetric encryption only since it only contains information related to the length of the header and body. It is designed to allow both the server and client to allocate just enough memory space as a buffer for messages to improve performance and prevent memory overflow. The fields of the header allow the server to verify the client ID and source to prevent cross-origin resource-sharing attacks and allow the client to associate the message with the transaction. Both the pre-header and header are designed to contain only the necessary information, while the body is to be extended as much as possible. Both the header and the body are encrypted with the shared secret exchanged via Kypber KEM.  
The fields of the message body depend on the message type indicated by the header as follows:  
1. **Handshake**: The message body from the client side includes the Kyber public key. The message body from the server side includes the encapsulated shared secret as cipher text. Both are in raw bytes encrypted by TLS.
2. **Discovery**: The message body from the client side is empty. The message body from the server side includes a list of nodes. The list of nodes is encoded in JSON format rather than raw bytes.
3. **Read**: The message body from the client side contains a list of the IDs and a list of the names of the nodes to be read. The server will return one read response per node, in which the body contains the ID and the name of the node, as well as the value.  
4. **Write**: The message body from the client side includes the ID and name of the node, as well as the value to be written. The message body from the server side contains the same fields. Both message bodies are encoded in JSON format.  
SRMCP adopts JSON encoding for the header and the body, which contains both the field name and value instead of value only. This allows the received information to be checked with a predefined schema to eliminate any unwanted or malicious data. Additionally, it supports a highly extendable message body without limiting data to a fixed location in the array of bytes. Hence, future extensions or arbitrary data structures could be more easily implemented. The SRMCP message does not include a checksum field because the AES-GCM can authenticate the message's integrity. Hence, additional checksum serves no purpose but only decreases the performance.