WebSphere MQ Telemetry Transport stellt Nachrichten gemäß den in der Servicequalität (Quality of Service, QoS) definierten Stufen zu. Diese Stufen werden nachfolgend beschrieben:
Die nachfolgende Tabelle zeigt die Protokollübertragung für QoS-Stufe 0.
Client | Nachricht und Richtung | Broker |
---|---|---|
QoS = 0 | PUBLISH |
Aktion: Nachricht für Subskribenten veröffentlichen |
Bei einer Nachricht mit QoS-Stufe 1 befindet sich eine Nachrichten-ID im Nachrichtenheader.
Die nachfolgende Tabelle zeigt die Protokollübertragung für QoS-Stufe 1.
Client | Nachricht und Richtung | Broker |
---|---|---|
QoS = 1 |
PUBLISH |
Aktionen:
|
Aktion: Nachricht verwerfen | PUBACK |
Wenn der Client keine PUBACK-Nachricht empfängt (entweder innerhalb einer in der Anwendung festgelegten Zeitdauer oder wenn ein Fehler festgestellt und die Kommunikationssitzung neu gestartet wird), sendet der Client die PUBLISH-Nachricht erneut, mit gesetztem DUP-Argument.
Wenn der Broker eine Nachricht doppelt vom Client empfängt, veröffentlicht er sie den Subskribenten erneut und versendet eine andere PUBACK-Nachricht.
Bei einer Nachricht mit QoS-Stufe 2 befindet sich eine Nachrichten-ID im Nachrichtenheader.
Die nachfolgende Tabelle zeigt die Protokollübertragung für QoS-Stufe 2.
Client | Nachricht und Richtung | Broker |
---|---|---|
QoS = 2 |
PUBLISH |
Aktion: Nachricht in Datenbank speichern |
PUBREC |
Nachrichten-ID = x | |
Nachrichten-ID = x | PUBREL |
Aktionen:
|
Aktion: Nachricht verwerfen | PUBCOMP |
Nachrichten-ID = x |
Wenn ein Fehler festgestellt wird oder eine definierte Zeitdauer abgelaufen ist, wird jeder Teil der Protokollübertragung mit festgelegtem DUP-Bit wiederholt. Die zusätzlichen Protokollübertragungen stellen sicher, dass die Nachricht dem Subskribenten nur einmal zugestellt wird.
Die QoS-Stufen 1 und 2 definieren, dass Nachrichten zugestellt werden müssen, daher speichert der Broker die Nachrichten in einer Datenbank. Probleme beim Zugriff des Brokers auf diese Daten haben möglicherweise den Verlust von Nachrichten zur Folge. Weitere Informationen hierzu sowie zu den Aktionen, die derlei Probleme minimieren, finden Sie unter Telemetrieanwendungen entwerfen.
In jedem Netzwerk besteht die Gefahr, dass bei Geräten oder Kommunikationsverbindungen Fehler auftreten. In einer derartigen Situation ist auf der einen Seite unter Umständen nicht bekannt, was auf der anderen Seite geschieht. Man spricht in diesem Fall von einem unbestätigten Status. In einer derartigen Situation beruht das Wissen über die Zuverlässigkeit der Zustellung von Nachrichten Geräte und Netze auf Annahmen.
WebSphere MQ Telemetry Transport geht davon aus, dass der Client und der Broker generell zuverlässig sind und dass eher der Kommunikationskanal unzuverlässig ist. Schlägt der Client fehl, handelt es sich dabei in der Regel um einen schwerwiegenden Fehler, nicht um einen vorübergehenden. Die Wahrscheinlichkeit, die Gerätedaten wiederherstellen zu können, ist gering. Einige Geräte besitzen einen nicht flüchtigen Speicher, beispielsweise Flash-ROM. Die Bereitstellung von permanentem Speicher im Clientgerät schützt die sensibelsten Daten vor einigen Ausfallrisiken.
Gehen die Ausfälle der Kommunikationsverbindung über das Grundmaß hinaus, wird die Ausfallmodusmatrix koplex, was zu mehr Szenarien führt als die Spezifikation für WebSphere MQ Telemetry Transport bewältigen kann.
Die Zeitverzögerung vor dem erneuten Senden (Wiederholungsintervall) einer unbestätigten Nachricht, ist anwendungsabhängig und wird nicht von der Protokollspezifikation festgelegt.