Retry-handling QoS

MQTT verwendet TCP als unterlagertes Transportprotokoll. TCP hat die Eigenschaft, dass Nachrichten im Falle einer funktionierenden Verbindung genau einmal und in korrekter Reihenfolge eintreffen. Alle Pakete einer MQTT Verbindung kommen also an der Gegenstelle an. Falls die TCP Verbindung unterbrochen wird, stehen mit QoS 1 und 2 Optionen zur Verfügung, dass die Nachrichten über mehrere TCP-Verbindungen hinweg zugestellt werden können.

MQTT3 erlaubte bereits eine wiederholte Nachrichtenzustellung bei unterbrechungsfreier TCP Verbindung. Dies konnte jedoch zur Folge haben, dass ein überlasteter MQTT Client im Zweifelsfall noch weiter überlastet wurde, z.B. wenn der Client für die Verarbeitung einer empfangenen Nachricht mehrere Sekunden braucht und in der Zwischenzeit der Message Broker die Nachricht nochmal verschickt weil er das Acknowledgement (noch) nicht erhalten hat.Die folgende Grafik veranschaulicht noch einmal den Empfangsvorgang einer Nachricht aus Sicht des Subscribers, welcher sich mit QoS 2 auf ein Topic am Message Broker subscribed hat:

Wenn der Empfängers nun durch eine Überlastung nicht sofort ein MQTT_PublishReceived Kommando nach dem MQTT_Publish versendet, wird der Message Broker bei MQTT3 einen erneuten Versand des Publishes vorbereiten und auf den Weg schicken. Die TCP-Verbindung ist in diesem Fall weiterhin aktiv. Dies wird in der folgenden Grafik veranschaulicht.

Durch eine neue Erweiterung in MQTT5, wird die wiederholte MQTT Nachrichtenübermittlung (Resend) bei bestehender TCP-Verbindung für Clients und Message Broker unterbunden.