# E-MQTT: End-to-End Synchronous and Asynchronous Communication Mechanisms in MQTT Protocol
## 5 Experimental Results
### End-to-End Delay  
In the first experiment, we measured response latency within the context of situations wherein the publisher's awareness of message reception by subscribers is essential. In E-MQTT, the subscriber does not need to create a separate PUBLISH packet for a response. As \begin{table}
\begin{tabular}{l l l} \hline \hline  & **PC 1** & **PC 2** \\ \hline Processor & AMD Ryzen 5 3500 6-Core & Intel® CoreTM i5-8250U CPU @ 1.60 \\  & Processor 3.60 GHz & GHz \\ RAM & 16 GB RAM & 4 GB RAM \\ OS & Windows 10 & Windows 10 \\ Network & Ethernet (1 Gbps link speed) & Wi-Fi \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Device specifications for delay measurement. a response packet to PUBLISH, the subscriber transmits the PUBREC packet. However, the existing MQTT requires an additional process to respond to the publisher. The subscriber must respond to the publisher by creating and sending a new PUBLISH packet. To facilitate this, the publisher is mandated to pre-configure subscription to an additional topic (referred to as topic B) enabling the reception of subscriber responses. Subsequently, the subscriber conveys its acknowledgement by publishing a PUBLISH packet with topic B. Upon the receipt of the aforementioned PUBLISH packet with topic B, the publisher effectively confirms successful reception of the original PUBLISH packet by the subscriber. Within the existing MQTT, we defined the end-to-end delay as the elapsed time from the moment the publisher sends a PUBLISH packet to the point when it receives the final response PUBLISH packet sent by the subscribers. In contrast, within the context of the proposed E-MQTT, this end-to-end delay was the elapsed time from the moment the publisher sends a PUBLISH packet to the point when it receives an aggregated PUBREC packet sent by the broker. The first experiment was conducted by increasing the number of subscribers, ranging from 10 to 80. Figure 14 shows the results of the experiment. The average end-to-end delay values of MQTT (QoS 2), asynchronous E-MQTT, and synchronous E-MQTT were 9.13, 6.84, and 8.49 milliseconds, respectively. Both synchronous and asynchronous E-MQTT demonstrated notably shorter delays when compared to the conventional MQTT. It is noteworthy that asynchronous E-MQTT consistently outperformed other scenarios across all cases. The synchronous E-MQTT, in contrast, requires an additional synchronization process in the publisher application unlike the asynchronous E-MQTT and conventional MQTT. In terms of message delivery and processing overhead, E-MQTT optimizes the response mechanism within the CM layer that is under the application layer. This differs from MQTT, which carries out the response procedure within \begin{table}
\begin{tabular}{c c c} \hline \hline  & **Publisher** & **Broker and Subscribers** \\ \hline
**Processor** & Apple M2 & 3.8 GHz Intel i5 \\
**RAM** & 32 GB RAM & 16 GB RAM \\
**Power** & 69.6 Wh Battery & AC \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Device specifications for battery usage experiment. Figure 14: Comparison of end-to-end delay results. the application layer by transmitting an independent PUBLISH packet as the response, which results in supplementary overhead. The broker, in turn, needs to ascertain the topic of the response PUBLISH packet, locate the relevant subscribers (which include the publisher), and send them the packet, which is also an additional overhead of the response mechanism of MQTT. Notably, the quantity of packets traversing between the broker and publisher equates to the number of subscribers. While the proposed E-MQTT involves the supplementary task of collecting response packets from subscribers, the broker can efficiently transmit a single response packet to the publisher. In summary, the asynchronous E-MQTT showed the shortest end-to-end delay compared to the other two cases, the synchronous E-MQTT and MQTT. This supremacy can be attributed to its omission of a synchronization process and any supplementary response procedures within the application layer.