Retry-handling QoS

MQTT uses TCP as its underlying transport protocol. TCP has the property that messages arrive exactly once and in the correct order in the case of a functioning connection. All packets of an MQTT connection therefore arrive at the remote terminal. If the TCP connection is interrupted, options are available with QoS 1 and 2 so that the messages can be delivered across multiple TCP connections.

MQTT3 already allowed repeated message delivery with an uninterrupted TCP connection. However, this could result in an overloaded MQTT client being further overloaded in case of doubt, e.g. if the client needs several seconds to process a received message and in the meantime the message broker sends the message again because it has not (yet) received the acknowledgement. The following figure illustrates the reception process of a message from the subscriber's point of view, which has subscribed to a topic at the message broker with QoS 2:

Now, if the receiver does not immediately send a MQTT_PublishReceived command after the MQTT_Publish due to an overload, the message broker at MQTT3 will prepare a resend of the publish and send it on its way. The TCP connection is still active in this case. This is illustrated in the following figure.

Due to a new extension in MQTT5, repeated MQTT message transmission (Resend) is prevented for clients and message brokers when a TCP connection is established.