MQTT delivers messages according to service levels defined in a Quality of Service (QoS) parameter.
The levels are described below:
At most once delivery.QoS 1
Messages are delivered according to the best efforts of the underlying TCP/IP network. No response is expected. No retry semantics are defined in the protocol. Consequently, the message will arrive at the destination broker either not at all or once. QoS 0 is also known as fire and forget.
At least once delivery.QoS 2
The arrival of a QoS 1 message at the broker, including its successful placement in a persistent store is acknowledged. In the event of identifiable failure of the communications link, or of the sending device, or after some period of time of non-receipt of the acknowledgement message, the sender will resend a duplicate message. Consequently, the message is certain to arrive, but could arrive more than once.
Exactly once delivery.
For QoS 2, additional protocol flows are employed above QoS 1 to ensure that duplicate messages are not delivered to the receiving application. This is the highest level of service, and is used when duplicate messages are undesirable. Of course, there is a price to be paid in terms of network traffic, but often this is acceptable because of the importance of the message content.
The QoS can be selected on a message-by-message basis, allowing less important messages to be published using QoS 0 and the most important messages to be delivered using QoS 2.
Publishing and subscribing clients both specify a QoS to use. When they differ, the micro broker sets the QoS or a message being sent to a client to the lower of the two specified values.
Assumptions for QoS levels 1 and 2
In any network, it is possible for devices or communication links to fail. If this happens, one end of the link might not know what is happening at the other end for some time. This is known as an in doubt window
. In this situation, assumptions have to be made about the reliability of the devices and networks involved in message delivery.
MQTT assumes that the client and broker are generally reliable, and that the communications channel is more likely to be unreliable. If the client device fails, it is typically a catastrophic failure, rather than a transient one. The possibility of recovering data from the device is low.
Some devices have non-volatile storage, for example, flash ROM. The provision of more persistent storage on the client device protects the most critical data from some modes of failure. Beyond the basic failure of the communications link, the failure mode matrix becomes complex, resulting in more scenarios than the specification for MQTT can handle.
The time delay (retry interval) before resending a message that has not been acknowledged is specific to the application, and is not defined by the protocol specification.
Parent topic: MQTT: XPD621