Ereignisse
17. März, 21 Uhr - 21. März, 10 Uhr
Nehmen Sie an der Meetup-Serie teil, um skalierbare KI-Lösungen basierend auf realen Anwendungsfällen mit Mitentwicklern und Experten zu erstellen.
Jetzt registrierenMQTT-Features, die vom MQTT Vermittler-Feature von Azure Event Grid unterstützt werden
MQTT ist ein Veröffentlichungs-Abonnement-Messagingtransportprotokoll, das für eingeschränkte Umgebungen entwickelt wurde. Es ist effizient, skalierbar und zuverlässig, was es zum Premiumstandard für die Kommunikation in IoT-Szenarien gemacht hat. MQTT Vermittler unterstützt Clients, die Nachrichten über MQTT v3.1.1, MQTT v3.1.1 über WebSockets, MQTT v5 und MQTT v5 über WebSockets veröffentlichen und abonnieren. MQTT Vermittler unterstützt auch die Kommunikation zwischen MQTT-Versionen (MQTT 3.1.1 und MQTT 5).
MQTT v5 führte viele Verbesserungen gegenüber MQTT v3.1.1 ein, um eine nahtlosere, transparentere und effizientere Kommunikation zu ermöglichen. Folgendes wurde hinzugefügt:
- Bessere Fehlerberichterstellung.
- Transparentere Kommunikationsclients durch Features wie Benutzereigenschaften und Inhaltstyp.
- Mehr Kontrolle für Clients über die Kommunikation durch Features wie Nachrichten- und Sitzungsablauf.
- Standardmäßige wichtige Muster wie das Anforderung-Antwort-Muster.
Ihre MQTT-Clients müssen die Verbindung über TLS 1.2 oder TLS 1.3 herstellen. Wenn Sie versuchen, diesen Schritt zu überspringen, treten Verbindungsfehler auf.
Verwenden Sie beim Herstellen einer Verbindung mit MQTT Vermittler die folgenden Ports für die Kommunikation über MQTT:
- MQTT v3.1.1 und MQTT v5 an TCP-Port 8883
- MQTT v3.1.1 über WebSocket und MQTTv5 über WebSocket an TCP-Port 443.
Das CONNECT-Paket sollte die folgenden Eigenschaften enthalten:
- Das Feld „ClientId“ ist erforderlich und sollte den Sitzungsnamen des Clients enthalten. Der Sitzungsname muss für den gesamten Namespace eindeutig sein. Sie können den Authentifizierungsnamen des Clients als Sitzungsnamen verwenden, wenn jeder Client eine Sitzung pro Client verwendet. Wenn ein Client mehrere Sitzungen verwendet, muss er für jede seiner Sitzungen unterschiedliche Werte für „ClientId“ verwenden.
- Das Feld „Username“ ist erforderlich, wenn Sie bei der Erstellung des Namespaces keinen Wert im Feld „alternativeAuthenticationNameSources“ ausgewählt haben. In diesem Fall müssen Sie den Authentifizierungsnamen Ihres Clients in das Feld „Username“ eingeben. Dieser Name muss mit dem angegebenen Authentifizierungsnamen und dem Wert im Zertifikatsfeld des Clients übereinstimmen, der bei der Erstellung der Clientressource angegeben wurde.
Erfahren Sie mehr über Clientauthentifizierung.
Die Unterstützung für mehrere Sitzungen ermöglicht Ihren MQTT-Anwendungsclients eine besser skalierbare und zuverlässigere Implementierung, indem sie eine Verbindung mit MQTT Vermittler mit mehreren aktiven Sitzungen gleichzeitig herstellen.
Bevor Sie dieses Feature verwenden, müssen Sie den Namespace so konfigurieren, dass mehrere Sitzungen pro Client zugelassen werden. Führen Sie die folgenden Schritte aus, um im Azure-Portal mehrere Sitzungen pro Client zu konfigurieren:
- Navigieren Sie im Azure-Portal zu Ihrem Namespace.
- Ändern Sie unter Konfiguration den Wert für maximale Clientsitzungen pro Authentifizierungsnamen in die gewünschte Anzahl von Sitzungen pro Client.
- Wählen Sie Übernehmen.
Hinweis
Aktualisieren Sie für die Azure CLI-Konfiguration die Eigenschaft MaxClientSessionsPerAuthenticationName in die Namespacenutzlast mit dem gewünschten Wert.
Die CONNECT-Pakete für jede Sitzung sollten die folgenden Eigenschaften umfassen:
- Geben Sie die Eigenschaft „Username“ im CONNECT-Paket an, um den Namen Ihrer Clientauthentifizierung anzugeben.
- Geben Sie die ClientID-Eigenschaft im CONNECT-Paket an, um den Sitzungsnamen zu kennzeichnen, sodass es für jeden Benutzernamen einen oder mehrere Werte für die ClientID gibt.
Beispielsweise ermöglichen die folgenden Kombinationen von „Username“ und „ClientIds“ im CONNECT-Paket dem Client „Mgmt-application“ das Herstellen einer Verbindung mit MQTT Vermittler über drei unabhängige Sitzungen:
- Erste Sitzung:
- Benutzername:
Mgmt-application - ClientId:
Mgmt-Session1
- Benutzername:
- Zweite Sitzung:
- Benutzername:
Mgmt-application - ClientId:
Mgmt-Session2
- Benutzername:
- Dritte Sitzung:
- Benutzername:
Mgmt-application - ClientId:
Mgmt-Session3
- Benutzername:
Weitere Informationen finden Sie unter Einrichten mehrerer Sitzungen für einen einzelnen Client.
- Wenn ein Client versucht, die aktive Sitzung eines anderen Clients zu übernehmen, indem er seinen Sitzungsnamen mit einem anderen Authentifizierungsnamen angibt, wird seine Verbindungsanforderung mit einem Fehler vom Typ „Nicht autorisiert“ abgelehnt. Wenn z. B. Client B versucht, eine Verbindung zu Sitzung 123 herzustellen, die zu diesem Zeitpunkt für Client A zugewiesen ist, wird die Anforderung von Client B abgewiesen. Wenn also derselbe Client versucht, die Verbindung mit denselben Sitzungsnamen und demselben Authentifizierungsnamen erneut herzustellen, kann er seine vorhandene Sitzung übernehmen.
- Wenn eine Client-Ressource gelöscht wird, ohne ihre Sitzung zu beenden, können andere Clients ihren Sitzungsnamen nicht verwenden, bis die Sitzung abläuft. Wenn z. B. Client B eine Sitzung mit dem Sitzungsnamen 123 erstellt und dann wird Client B gelöscht, kann Client A keine Verbindung zu Sitzung 123 herstellen, bis diese abläuft.
- Der Grenzwert für die Anzahl der Sitzungen pro Client gilt jederzeit für Online- und Offlinesitzungen. Angenommen, ein Namespace mit den maximalen Clientsitzungen pro Authentifizierungsname ist auf 1 festgelegt. Wenn Client A eine Verbindung zu einer dauerhaften Sitzung 123 herstellt und dann getrennt wird, kann Client A keine Verbindung zu einer neuen Sitzung 456 herstellen, da seine Sitzung 123 auch dann noch aktiv ist, wenn sie offline ist. Dementsprechend wird empfohlen, dass derselbe Client immer wieder mit denselben statischen Sitzungsnamen verbunden wird, anstatt bei jeder erneuten Verbindung einen neuen Sitzungsnamen zu generieren.
Das MQTT Vermittler-Feature von Azure Event Grid unterstützt die folgenden MQTT-Features:
MQTT Vermittler unterstützt QoS 0 und 1, welche die Garantie der Nachrichtenübermittlung für PUBLISH- und SUBSCRIBE-Pakete zwischen Clients und MQTT Vermittler definieren. QoS 0 garantiert eine At-Most-Once-Übermittlung. Nachrichten mit QoS 0 werden weder vom Abonnenten bestätigt noch vom Herausgeber erneut übertragen. QoS 1 garantiert eine At-Most-Once-Übermittlung. Nachrichten werden vom Abonnenten bestätigt und vom Herausgeber erneut gesendet, wenn sie nicht bestätigt wurden. QoS ermöglicht es Ihren Clients, die Effizienz und Zuverlässigkeit der Kommunikation zu steuern.
MQTT Vermittler unterstützt persistente Sitzungen für MQTT v3.1.1, indem MQTT Vermittler die Informationen über die Sitzung eines Clients im Falle von Verbindungsunterbrechungen beibehält, um die Zuverlässigkeit der Kommunikation sicherzustellen. Diese Informationen umfassen die Abonnements des Clients und verpasste/unbestätigte QoS 1-Nachrichten. Clients können eine persistente Sitzung konfigurieren, indem sie das cleanSession-Flag im CONNECT-Paket auf „false“ festlegen.
MQTT v5 führte die Neustart- und Sitzungsablauffunktionen als Verbesserung gegenüber MQTT v3.1.1 bei der Behandlung von Sitzungspersistenz ein. „Sauberer Start“ ist ein Feature, das es einem Client ermöglicht, eine neue Sitzung mit MQTT Vermittler zu beginnen und alle vorherigen Sitzungsdaten zu verwerfen. Mit „Sitzungsablauf“ kann ein Client MQTT Vermittler darüber informieren, wenn eine inaktive Sitzung als abgelaufen gilt und automatisch entfernt wird. Im CONNECT-Paket kann ein Client aus Sicherheitsgründen oder zur Vermeidung möglicher Datenkonflikte, die während der vorherigen Sitzung aufgetreten sind, das Flag für den sauberen Start auf „true“ und/oder ein kurzes Ablaufintervall für die Sitzung festlegen. Ein Client kann auch den sauberen Start auf „false“ und/oder ein langes Ablaufintervall für die Sitzung festlegen, um die Zuverlässigkeit und Effizienz von persistenten Sitzungen sicherzustellen.
Sie können das maximale Intervall für den Ablauf der Sitzung konfigurieren, das für alle Ihre Clients, die sich mit dem Event Grid-Namespace verbinden, zulässig ist. Bei MQTT v3.1.1-Clients wird der konfigurierte Grenzwert als Standardintervall für den Ablauf von Sitzungen für alle persistenten Sitzungen verwendet. Bei MQTT v5-Clients wird der konfigurierte Grenzwert als maximaler Wert für die Eigenschaft Sitzungsablaufintervall im CONNECT-Paket angewendet; jeder Wert, der den Grenzwert überschreitet, wird angepasst. Der Standardwert für diese Namespaceeigenschaft ist 1 Stunde und kann auf bis zu 8 Stunden verlängert werden. Führen Sie die folgenden Schritte aus, um das maximale Ablaufintervall für Sitzungen im Azure-Portal zu konfigurieren:
- Navigieren Sie im Azure-Portal zu Ihrem Namespace.
- Ändern Sie unter Konfiguration den Wert für das Maximale Ablaufintervalls einer Sitzung in Stunden in den gewünschten Grenzwert.
- Wählen Sie Übernehmen.
MQTT Vermittler unterhält eine Warteschlange mit Nachrichten für jede aktive MQTT-Sitzung, die nicht verbunden ist, bis der Client sich erneut mit MQTT Vermittler verbindet, um die Nachrichten in der Warteschlange zu empfangen. Wenn ein Client keine Verbindung herstellt, um die in der Warteschlange stehenden QOS1-Nachrichten zu empfangen, beginnt die Sitzungswarteschlange, die Nachrichten zu sammeln, bis sie ihren Grenzwert erreicht: 100 Nachrichten oder 1 MB. Sobald die Warteschlange während der Laufzeit der Sitzung ihren Grenzwert erreicht, wird die Sitzung beendet.
Last Will and Testament (LWT) benachrichtigt Ihre MQTT-Clients mit den abrupten Trennungen anderer MQTT-Clients. Sie können LWT verwenden, um einen vorhersehbaren und zuverlässigen Kommunikationsfluss zwischen MQTT-Clients während unerwarteter Trennungen zu gewährleisten, was für Szenarien nützlich ist, in denen Echtzeitkommunikation, Systemzuverlässigkeit und koordinierte Aktionen kritisch sind. Clients, die an komplexen Aufgaben zusammenarbeiten, können auf LWT-Nachrichten voneinander reagieren, indem sie ihr Verhalten anpassen, Aufgaben neu verteilen oder bestimmte Verantwortlichkeiten übernehmen, um die Leistung und Stabilität des Systems aufrechtzuerhalten. Um LWT zu verwenden, kann ein Client die Willensnachricht und das Willensthema angeben, und die restlichen Eigenschaften des Willens im CONNECT-Paket während der Verbindung angeben. Wenn der Client abrupt getrennt wird, veröffentlicht der MQTT-Broker die Willensnachricht an alle Clients, die das Willensthema abonniert haben. Um das Rauschen von schwankenden Trennungen zu reduzieren, kann der Client das Verzögerungsintervall auf einen Wert festlegen, der größer als 0 ist. Wenn der Client in diesem Fall abrupt getrennt wird, die Verbindung jedoch wiederhergestellt wird, bevor das Verzögerungsintervall abläuft, wird die Meldung nicht veröffentlicht.
MQTT Vermittler unterstützt Benutzereigenschaften in MQTT v5 PUBLISH-Paketen, mit denen Sie benutzerdefinierte Schlüssel/Wert-Paare in den Nachrichtenheader einfügen können, um mehr Kontext über die Nachricht bereitzustellen. Die Anwendungsfälle für Benutzereigenschaften sind vielfältig. Sie können dieses Feature verwenden, um den Zweck oder den Ursprung der Nachricht anzugeben, sodass der Empfänger die Nachricht verarbeiten kann, ohne die Nutzdaten analysieren zu müssen, und somit Computingressourcen spart. Beispielsweise könnte eine Nachricht mit einer Benutzereigenschaft, die ihren Zweck als „Warnung“ angibt, eine andere Verarbeitungslogik auslösen als eine mit dem Zweck „Information“.
MQTTv5 hat Felder im MQTT PUBLISH-Paketheader eingeführt, die den Kontext für die Antwortnachricht im Anforderung-Antwort-Muster bereitstellen. Zu diesen Feldern gehören ein Antwortthema und eine Korrelations-ID, die der Antwortdienst ohne vorherige Konfiguration in der Antwort verwenden kann. Die Antwortinformationen ermöglichen eine effizientere Kommunikation für das Anforderung-Antwort-Standardmuster, das in Command-and-Control-Szenarien verwendet wird.
In MQTT v5 ermöglicht das Ablaufintervall für Nachrichten eine konfigurierbare Lebensdauer. Das Ablaufintervall für Nachrichten ist definiert als das Zeitintervall zwischen dem Zeitpunkt, an dem eine Nachricht im MQTT Vermittler veröffentlicht wird, und dem Zeitpunkt, an dem der MQTT Vermittler die Nachricht verwerfen muss, wenn sie nicht übermittelt wurde. Dieses Feature ist in Szenarien nützlich, in denen Nachrichten nur für eine bestimmte Zeit gültig sind, z. B. bei zeitabhängigen Befehlen, Echtzeitdatenströmen oder Sicherheitswarnungen. Indem Sie ein Ablaufintervall für Nachrichten festlegen, kann MQTT Vermittler veraltete Nachrichten automatisch entfernen und so sicherstellen, dass nur relevante Informationen für die Abonnenten verfügbar sind. Wenn das Ablaufintervall einer Nachricht auf Null festgelegt ist, bedeutet dies, dass die Nachricht niemals ablaufen sollte.
In MQTT v5 ermöglichen Themenaliase einem Client, einen kürzeren Alias anstelle des vollständigen Themennamens in der veröffentlichten Nachricht zu verwenden. MQTT Vermittler verwaltet eine Zuordnung zwischen dem Themenalias und dem aktuellen Themennamen. Mit diesem Feature können Sie Netzwerkbandbreite sparen und die Größe des Nachrichtenheaders reduzieren, insbesondere bei Themen mit langen Namen. Dies ist nützlich in Szenarien, in denen dasselbe Thema wiederholt in mehreren Nachrichten veröffentlicht wird, z. B. in Sensornetzwerken. MQTT Vermittler unterstützt bis zu 10 Themenaliase. Ein Client kann ein Feld für Themenaliase im PUBLISH-Paket verwenden, um den vollständigen Themennamen durch den entsprechenden Alias zu ersetzen.
In MQTT v5 bezieht sich die Flusssteuerung auf den Mechanismus zur Verwaltung der Rate und Größe von Nachrichten, die ein Client verarbeiten kann. Die Flusssteuerung kann konfiguriert werden, indem Sie die Parameter „Maximum Packet Size“ und „Receive Maximum“ im CONNECT-Paket festlegen. Mit dem Parameter „Receive Maximum“ kann der Client die Anzahl der vom Broker gesendeten Nachrichten auf die Anzahl der Nachrichten begrenzen, die der Client verarbeiten kann. Der Parameter „Maximum Packet Size“ definiert die maximale Größe der Pakete, die der Client empfangen kann. MQTT Vermittler hat eine maximale Nachrichtengröße von 512 KiB. Dieses Feature gewährleistet die Zuverlässigkeit und Stabilität der Kommunikation bei eingeschränkten Geräten mit begrenzter Verarbeitungsgeschwindigkeit oder Speicherkapazität.
Bei MQTT v5 ist MQTT Vermittler in der Lage, negative Bestätigungen (Negative Acknowledgments, NACKs) und vom Server initiierte DISCONNECT-Pakete zu senden, die dem Client weitere Informationen über Fehler bei der Nachrichtenübermittlung oder der Verbindung bereitstellen. Diese Features helfen dem Client bei der Diagnose der Fehlerursache und bei der Ergreifung geeigneter Aktionen zur Entschärfung des Problems. MQTT-Broker verwendet die Ursachencodes, die in der MQTT v5 Specification definiert sind.
MQTT Vermittler fügt in Zukunft weitere MQTT v5- und MQTT v3.1.1-Features hinzu, um sich stärker an den MQTT-Spezifikationen zu orientieren. In der folgenden Liste werden die aktuellen Unterschiede zwischen Features beschrieben, die vom MQTT Vermittler und den MQTT-Spezifikationen unterstützt werden:
MQTT v5 unterscheidet sich derzeit in den folgenden Punkten von der MQTT v5-Spezifikation:
- Gemeinsame Abonnements werden noch nicht unterstützt.
- Das Flag „Retain“ (Beibehalten) wird noch nicht unterstützt.
- Das maximale Verzögerungsintervall beträgt 300.
- Maximaler QoS-Wert ist 1.
- Maximale Paketgröße beträgt 512 KiB
- Die Reihenfolge der Nachrichten ist nicht garantiert.
- Abonnementbezeichner werden nicht unterstützt.
- Zugewiesene Clientbezeichner werden noch nicht unterstützt.
- Maximaler Wert für den Themenalias ist 10. Der Server weist derzeit keine Themenaliase für ausgehende Nachrichten zu. Clients können Themenaliase innerhalb der festgelegten Grenzen zuweisen und verwenden.
- CONNACK gibt die Eigenschaft für Antwortinformationen nicht zurück, auch wenn die CONNECT-Anforderung die Eigenschaft für Anforderungsantwortinformationen enthält.
- Benutzereigenschaften für CONNECT-, SUBSCRIBE-, DISCONNECT-, PUBACK-, AUTH-Pakete werden vom Dienst nicht verwendet, und deshalb nicht unterstützt. Wenn eine dieser Anforderungen Benutzereigenschaften enthält, schlägt die Anforderung fehl.
- Wenn der Server ein PUBACK von einem Client mit nicht erfolgreichem Antwortcode empfängt, wird die Verbindung beendet.
- Das Keepalive-Maximum beträgt 1,160 Sekunden.
MQTT v5 unterscheidet sich derzeit in den folgenden Punkten von der MQTT v3-Spezifikation:
- QoS2 und das Retain-Flag (Beibehalten) werden noch nicht unterstützt. Eine Veröffentlichungsanforderung mit einem Retain-Flag oder einem QoS2 ist fehlerhaft und schließt die Verbindung.
- Die Reihenfolge der Nachrichten ist nicht garantiert.
- Das Keepalive-Maximum beträgt 1,160 Sekunden.
Dieses Repository enthält Codebeispiele in C#, C und Python, die zeigen, wie Telemetriedaten und Befehle gesendet sowie Warnungen übertragen werden. Die über die Beispiele erstellten Zertifikate sind für Tests geeignet, eignen sich jedoch nicht für Produktionsumgebungen.
Weitere Informationen über MQTT:
Erfahren Sie mehr über MQTT Vermittler:
Zusätzliche Ressourcen
Training
Zertifizierung
Microsoft Certified: Azure Cosmos DB Developer Specialty - Certifications
Schreiben Sie effiziente Abfragen, erstellen Sie Indizierungsrichtlinien, verwalten Sie und Sie Ressourcen in der SQL-API und im SDK mit Microsoft Azure Cosmos DB bereit.