MQTT: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
Zeile 35: | Zeile 35: | ||
*Beim Verbindungsaufbau können Clients einen „letzten Willen“ in Form einer Nachricht definieren. | *Beim Verbindungsaufbau können Clients einen „letzten Willen“ in Form einer Nachricht definieren. | ||
*Falls die Verbindung zum Client verloren geht, wird diese Nachricht publiziert und dabei an die entsprechenden Abonnenten gesendet. | *Falls die Verbindung zum Client verloren geht, wird diese Nachricht publiziert und dabei an die entsprechenden Abonnenten gesendet. | ||
− | + | *MQTT wird üblicherweise über TCP benutzt und hat einen fixen Header. Das erste Byte enthält den Nachrichtentyp (4 Bit) und, je nach Nachrichtentyp, weitere Flags. | |
− | MQTT wird üblicherweise über TCP benutzt und hat einen fixen Header. Das erste Byte enthält den Nachrichtentyp (4 Bit) und, je nach Nachrichtentyp, weitere Flags. | + | =Es gibt folgende Nachrichtentypen= |
+ | *CONNECT | ||
+ | *CONNACK | ||
+ | *PUBLISH | ||
+ | *PUBACK | ||
+ | *PUBREC | ||
+ | *PUBREL | ||
+ | *PUBCOMP | ||
+ | *SUBSCRIBE | ||
+ | *SUBACK | ||
+ | *UNSUBSCRIBE | ||
+ | *UNSUBACK | ||
+ | *PINGREQ | ||
+ | *PINGRESP | ||
+ | *DISCONNECT | ||
+ | *AUTH (ab MQTT Version 5.0) |
Version vom 18. März 2024, 19:42 Uhr
MQTT: Einführung und Grundlagen
- MQTT (ursprünglich MQ Telemetry Transport) ist ein offenes Netzwerkprotokoll, das für Machine-to-Machine-Kommunikation (M2M) entwickelt wurde.
- Es ermöglicht, trotz hoher Verzögerungen oder beschränkter Netzwerke die Kommunikation zwischen Geräten.
- Entsprechende Geräte reichen von Sensoren und Aktoren, Mobiltelefonen, eingebetteten Systemen in Fahrzeugen oder Laptops bis zu voll entwickelten Rechnern.
- MQTT war bis zur Version 3.1 ein Akronym für MQ Telemetry Transport,wobei MQ von MQSeries abgeleitet ist und für Message Queueing steht.
- Mit Version 3.1.1 wurde definiert, dass MQTT für kein Akronym steht.
- Das MQTT-Protokoll ist auch unter älteren Namen wie „WebSphere MQTT“ (WMQTT), „SCADA-Protokoll“ oder „MQ Integrator SCADA Device Protocol“ (MQIsdp) bekannt.
- Die Internet Assigned Numbers Authority (IANA) reserviert für MQTT die Ports 1883 und 8883. MQTT-Nachrichten können mit dem TLS-Protokoll verschlüsselt werden.
- Ein MQTT-Server („Broker“) hält die gesamte Datenlage seiner Kommunikationspartner und kann so als Zustands-Datenbank benutzt werden.
- So ist es möglich, kleine unperformante MQTT-Geräte mit einem MQTT-Broker zu verbinden*
- Die Geräte sammeln Daten oder nehmen Befehle entgegen, während ein komplexes Lagebild nur auf dem MQTT-Broker entsteht.
- Stelleingriffe können so von einer oder mehreren leistungsfähigen Instanzen an den MQTT-Broker übermittelt und auf die einzelnen Geräte verbreitet werden.
- Dadurch eignet sich MQTT sehr gut für Automatisierungslösungen und findet im Bereich IoT durch die einfache Verwendung große Verbreitung.
Spezifikation
- Die MQTT-Spezifikation unterscheidet TCP/IP-basierte und Nicht-TCP/IP-Netzwerke und Systeme.
- Haupt-Spezifikation
- Das Protokoll ermöglicht auf eine einfache Art ein Beobachter-Verhaltensmuster. Es ist besonders geeignet für Verbindungen, die nur einen geringen Verwaltungsdatenanteil erlauben. Der OASIS-*Standardisierungsprozess basiert auf Version 3.1 der MQTT-Spezifikation.
- Im Januar 2018 wurde Version 5 veröffentlicht, die die Verwendung für Entwickler komfortabler machen soll.
- Spezifikation von MQTT-SN (ehemals MQTT-S), Version 1.2 (MQTT für Sensorgeräte)
- Ausgelegt für eingebettete Geräte in non-TCP/IP-Netzwerken, wie zum Beispiel ZigBee. MQTT-SN ist ein Nachrichtenprotokoll nach dem Beobachter-Muster für Sensornetze.
- Es erweitert MQTT für die Nutzung über TCP/IP-Infrastruktur hinaus und ist besonders optimiert für die Nutzung mit Sensor- und Aktor-Lösungen.
- Der ursprüngliche Name war MQTT-S. Dieser erzeugte jedoch Missverständnisse (s für secure?), so dass 2013 eine Umbenennung in MQTT-SN angestoßen wurde (SN für Sensor Networks).
Protokoll
- MQTT ist ein Client-Server-Protokoll.
- Clients senden dem Server (“Broker”) nach Verbindungsaufbau Nachrichten mit einem Topic, welches die Nachricht hierarchisch einstuft.
- Zum Beispiel Küche/Kühlschrank/Temperatur oder Auto/Rad/3/Luftdruck.
- Die Topics müssen vorher auch nicht konfiguriert werden. Clients können diese Topics abonnieren, wobei der Server die empfangenen Nachrichten an die entsprechenden Abonnenten weiterleitet.
- Nachrichten bestehen immer aus einem Topic und dem Nachrichteninhalt.
- Nachrichten werden mit einer definierbaren Quality of Service versendet:
- at most once (die Nachricht wird einmal gesendet und kommt bei Verbindungsunterbrechung möglicherweise nicht an),
- at least once (die Nachricht wird so lange gesendet, bis der Empfang bestätigt wird, und kann beim Empfänger mehrfach ankommen)
- exactly once (hierbei wird sichergestellt, dass die Nachricht auch bei Verbindungsunterbrechung genau einmal ankommt).
- Außerdem kann mit dem Retain-Flag der Server angewiesen werden, die Nachricht zu diesem Topic zwischenzuspeichern.
- Clients, die dieses Thema neu abonnieren, bekommen als erstes die zwischengespeicherte Nachricht zugestellt.
- Beim Verbindungsaufbau können Clients einen „letzten Willen“ in Form einer Nachricht definieren.
- Falls die Verbindung zum Client verloren geht, wird diese Nachricht publiziert und dabei an die entsprechenden Abonnenten gesendet.
- MQTT wird üblicherweise über TCP benutzt und hat einen fixen Header. Das erste Byte enthält den Nachrichtentyp (4 Bit) und, je nach Nachrichtentyp, weitere Flags.
Es gibt folgende Nachrichtentypen
- CONNECT
- CONNACK
- PUBLISH
- PUBACK
- PUBREC
- PUBREL
- PUBCOMP
- SUBSCRIBE
- SUBACK
- UNSUBSCRIBE
- UNSUBACK
- PINGREQ
- PINGRESP
- DISCONNECT
- AUTH (ab MQTT Version 5.0)