# E-MQTT: End-to-End Synchronous and Asynchronous Communication Mechanisms in MQTT Protocol
## 3 E-Mqtt
### Overview of End-to-End Communication Methods  
E-MQTT employs a four-way handshaking process connecting the publisher and subscriber through the broker. Figure 5 shows the end-to-end communication process in E-MQTT. The communication flow within E-MQTT mirrors that of MQTT QoS 2, which implies that all the MQTT packets are guaranteed to be delivered exactly once to a target node. In E-MQTT, the main purpose is not that the publisher wants to confirm whether its message is successfully received by subscribers, but that the publisher can check when its message is received by at least some specified number of subscribers. To this end,  
Figure 4: End-to-end confirmation process of query reception by n subscribers in E-MQTT (QoS 3). Figure 3: End-to-end confirmation process of query reception by one subscriber in E-MQTT (QoS 3). E-MQTT modified the message publishing process from MQTT as shown in the gray-colored tasks in Figure 5. Initially, the publisher configures the minimum number of packets to wait for (_waited_packet_num_) and stores the PUBLISH packet to be sent (1). If the number of response packets to be waited for is 1 or more, E-MQTT initiates the synchronous end-to-end communication. If the number is 0, the asynchronous end-to-end communication proceeds. While the _waited_packet_num_ field is a mandatory component, the publisher also can optionally set a list of subscriber identifiers (_subscriber_id(s)_). This additional field facilitates the identification of designated subscribers by the publisher. Each subscriber identifier (ID) is a globally unique label. To use the _subscriber_id(s)_ field, the publisher must request a list of subscriber IDs from the broker, facilitating the selection of a subset of subscribers. However, it is worth noting that since this additional constraint could potentially infringe upon the principle of the publish-subscribe model's loosely anonymous communication, the inclusion of the _subscriber_id(s)_ field remains optional. Subsequently, the publisher proceeds to release the PUBLISH packet with topic \(T\) (2). This PUBLISH packet is transmitted to the broker. In the synchronous communication scenarios, the publisher enters the suspended state after transmitting the PUBLISH packet (3). Figure 5: The communication process of E-MQTT. In contrast, during asynchronous communication, the publisher remains unsuspended and seamlessly advances to the subsequent task (4). Upon receiving the PUBLISH packet, the broker promptly disseminates it to all subscribers of topic \(T\) like MQTT (5). Once the PUBLISH packet is stored, a subscriber initiates a response via the PUBREC packet (6). When the broker receives the PUBREC packet from a subscriber, the broker answers with the PUBREL packet (7). Following this, the broker evaluates the _waited_packet_num_ and _subscriber_id(s)_ fields to determine whether it forwards the PUBREC packet to the publisher or not (8). If _waited_packet_num_ is less than or equal to 0 (asynchronous E-MQTT), the broker forwards the first PUBREC packet (9). Conversely, if _waited_packet_num_ is greater than 0 (synchronous E-MQTT), the broker scrutinizes the optional _subscriber_id(s)_ field to determine whether it counts the number of received PUBREC packets or not (10). If _subscriber_id(s)_ is empty or it contains the sender of the PUBREC packet, the broker increases the count of received response packets. Subsequently, the broker compares the number of PUBREC packets it has gathered from the subscribers with _waited_packet_num_. If the number of received response packets becomes equal to or greater than _waited_packet_num_, the broker sends one aggregated PUBREC packet to the publisher (11). This action enables the publisher to validate that the number of subscribers, as set by itself, has successfully received the published message. Upon reception of the PUBREC packet, the publisher proceeds to remove the stored PUBLISH packet. Subsequently, the publisher transmits the PUBREL packet to the broker and stores the PUBREL packet (12).