MQTT protocol specifies the quality of service, which guarantees the reliability of message delivery under different network environments. The design of QoS is the focus of the MQTT protocol. As a protocol specifically designed for IoT scenarios, MQTT's operating scenarios are not only for PC, but also in a wider range of narrow-bandwidth networks and low-power devices. If the problem of transmission quality can be solved at the protocol layer, it will provide a great convenience for the development of the Internet of things applications.
MQTT has designed 3 QoS levels.
QoS 0 is a "fire and forget" message sending mode: After a sender (possibly Publisher or Broker) sends a message, it no longer cares whether it is sent to the other party or sets up any resending mechanism.
QoS 1 includes a simple resending mechanism. After the Sender sends a message, it waits for the receiver's ACK. If it does not receive the ACK, it resends the message. This mode can guarantee that the message can arrive at least once, but it cannot guarantee that the message is repeated.
QoS 2 designed a resending and repeating message discovery mechanism to ensure the message will arrive only once.
When QoS is 0, the publish of messages depends on the capabilities of the underlying network. The publisher will publish the message only once, the receiver will not answer the message, and the publisher will not save and resend the message. Messages have the highest transmission efficiency at this level, but may not be delivered once.
When the QoS is 1, the message can be guaranteed to be published at least once. MQTT guarantees QoS 1 through a simple ACK mechanism. The publisher will publish the message and wait for the response of the receiver's PUBACK packet. If the PUBACK response is not received within the specified time, the publisher will set the message's DUP to 1 and resend the message. The receiver should respond to the PUBACK message when receiving a message with QoS 1. The receiver may accept the same message multiple times. Regardless of the DUP flag, the receiver will treat the received message as a new message and send a PUBACK packet as a response.
When the QoS is 2, publishers and subscribers ensure that messages are published only once through two sessions. This is the highest level of service quality, and message loss and duplication are unacceptable. There is an additional cost to using this quality of service level.
After the publisher publishes a message with a QoS of 2, it will store the published message and wait for the receiver to reply with the PUBREC message. After the publisher receives the PUBREC message, it can safely discard the previously published message because it already knows the receiver successfully received the message. The publisher saves the PUBREC message and responds with a PUBREL, waiting for the receiver to reply with the PUBCOMP message. When the sender receives the PUBCOMP message, it will clear the previously saved state.
When the receiver receives a PUBLISH message with a QoS of 2, it processes the message and returns a PUBREC in response. When the receiver receives the PUBREL message, it discards all saved states and responds with PUBCOMP.
Whenever packet loss occurs during transmission, the sender is responsible for resending the previous message. This is true regardless of whether the sender is Publisher or Broker. Therefore, the receiver also needs to respond to each command message.
QoS of MQTT publishing messages is not end-to-end, but between the client and the server. The QoS level at which subscribers receive MQTT messages ultimately depends on the QoS of the published message and the QoS of the topic subscription.
You can refer the following table for the message QoS that the client received in different situations:
|QoS of publish||QoS of subscribe||QoS of received message|
The higher QoS level corresponds to more complicated processes and the greater the consumption of system resources. The application can choose the appropriate QoS level according to their network scenarios and business requirements.
In this project, we will implement remote control LED lights via NodeMCU(ESP8266) and MQTT broker, and use the Arduino IDE to program NodeMCU ESP8266.
Four years after the MQTT 3.1.1 has been released and became the OASIS standard, MQTT 5.0 was released, which is a significant improvement and upgrade.
The message retention function of [EMQ X MQTT Broker](https://emqx.io) is implemented by the `emqx_retainer` plugin, which is enabled by default. By modifying the configuration of the` emqx_retainer` plugin, you can adjust the EMQ X Broker's retention message Location, restrict the number of retained messages and maximum payload length, and adjust the expiration time of retained messages.