MQTT - Message Queue Telemetry Transport Protocol
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
MQTT - Message Queue Telemetry
Transport Protocol
Sommersemester 2015
zur Vorlesung 'Seminar'
Bearbeitet von:
Richard Okuniewicz
(Matrikelnummer: 44521)
Johannes Seibold
(Matrikelnummer: 48989)
Betreuer:
Prof. Dr. Winfried Bantel
Hochschule für Technik und Wirtschaft Aalen
Fakultät Elektronik und Informatik
Studiengang Informatik
Inhaltsverzeichnis
1 Einleitung 3
1.1 De nition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Inhalte und Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Grundlagen 5
2.1 Was sind Telemetrie-Daten ? . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Machine-to-Machine-Kommunikation (M2M) . . . . . . . . . . . . . . 5
2.3 Kommunikationsarchitekturen und -muster im Vergleich . . . . . . . 6
2.3.1 Client/Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.2 Request/Response . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.3 Publish/Subscribe . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Funktionsweise MQTT 11
3.1 Einsatzbereiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Beschreibung des Standards . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1 Terminologie . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.2 MQTT Kontroll Paket Format . . . . . . . . . . . . . . . . . . 13
3.2.3 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Einordnung des MQTT-Protokolls . . . . . . . . . . . . . . . . . . . . 17
3.4 MQTT for Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . 17
3.5 Vergleich mit anderen Protokollen . . . . . . . . . . . . . . . . . . . . 19
4 Installation 20
4.1 Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5 Evaluierung 28
6 Fazit und Ausblick 29
Abbildungsverzeichnis 30
Tabellenverzeichnis 31
1
Listing-Verzeichnis 32
Literaturverzeichnis 33
2
1 Einleitung
1.1 De nition
Message Queue Telemetry Transport (MQTT) wurde 1999 von Andy Stanford-Clark
von IBM und Arlen Nipper von Arcom (jetzt Eurotech) entwickelt und ist ein leicht-
gewichtiges Nachrichten-Protokoll, das für die Übertragung von Telemetrie-Daten
vor allem in Gebieten mit begrenzter Netzwerkkapazität verwendet wird. [1] Da es
sich hierbei um ein Machine-to-Machine-Protokoll handelt, ist es ebenfalls auch ein
wichtiger Bestandteil des Internets der Dinge.
1.2 Motivation
Das Internet bietet viele Möglichkeiten sich auszutauschen und miteinander zu kom-
munizieren. Nun stelle man sich vor, neben Personen könnten dies auch Gegenstände
in vollem Umfang nutzen. Das Internet der Dinge (englisch: Internet of Things, kurz:
IoT) ist eines der aktuellsten und wichtigsten Themen der IT. Wie der Name schon
andeutet, beschreibt es das Verbinden von Dingen oder genauer, das Erschaen von
intelligenten Geräten, die selbstständig und unabhängig vom äuÿeren Einwirken
durch den Menschen untereinander kommunizieren und handeln. Hier kann es sich
auch um einfache und alltägliche Gegenstände handeln. Der Unterschied besteht
darin, dass diese beispielsweise mit einem eingebetteten System ausgerüstet sind,
um deren Verhalten und Kommunikation zu steuern. Seien es Kühlschränke, die
eigenständig Milch und Butter nachkaufen oder Waschmaschinen, die genau dann
waschen, wenn der Strom gerade günstig ist; den Anwendungsbereichen sind keine
Grenzen gesetzt. Sinn und Zweck des IoT bestehen darin, dem Menschen in seinem
täglichen Umfeld weitestgehend unmerklich zu unterstützen. Ferner werden dadurch
Prozesse wesentlich beschleunigt und zusätzlich Kosten eingespart. Ein aktuelles und
praxisnahes Beispiel, das vermutlich jeder einmal genutzt hat, ist eine von Logis-
tikunternehmen zur Verfügung gestellte Online-Paketverfolgung. Dabei kann man
über eine Webseite den aktuellen Status oder den Standort der Lieferung abrufen.
Die Informationen werden durch das Scannen des Strichcodes automatisch überge-
ben. Übertragen auf das vorhergehende Argument lässt sich nun feststellen, dass die
Nachfrage des Empfängers nach dem Aktuellen Stand der Lieferung über das Telefon
oder sonstige Mittel nicht mehr notwendig ist und somit auch Kosten wegfallen.
Trotz der Relevanz des Themas be ndet sich das Internet der Dinge immer noch im
Anfangsstadium. Stand 2014 waren ca. 3,9 Milliarden Geräte miteinander Verbun-
den. Laut dem Forschungsinstitut Gartner wird jedoch vermutet, dass dies bis 2020
3
mit schätzungsweise über 25 Milliarden Geräte der Fall sein wird. [2] Das liegt ins-
besondere daran, dass eine Vernetzung von Gegenständen erst mit der steigenden
Leistung bzw. Komplexität der Technologie umfassend möglich wird. Schlussend-
lich könnte man zusammenfassen, dass obwohl das IoT an sich noch relativ jung
ist, es bereits schon in naher Zukunft einen beträchtlichen Stellenwert in unserer
Gesellschaft haben wird.
1.3 Inhalte und Ziele
Im Rahmen dieser Seminararbeit wird der Paketaufbau und die Funktionsweise des
Nachrichten-Protokolls MQTT näher beschrieben. Dabei ist es notwendig auch auf
Grundbegrie, die für das Verständnis dieser Thematik notwendig sind, einzuge-
hen. Über das Beispiel einer selbst erstellten praktischen Anwendung werden die
Einsatzmöglichkeiten des Protokolls veranschaulicht. Unter anderem wird dabei auf
folgende Punkte näher eingegangen:
• Was ist MQTT und wie funktioniert es ?
• Zusammenspiel vom Internet der Dinge und Machine-to-Machine Kommuni-
kation mit MQTT ?
• De nition Telemetrie und Einsatzbereiche.
• Einsatzmöglichkeiten vom MQTT.
• Nach welchem Prinzip funkioniert MQTT und welche andere Kommunikati-
onsmuster gibt es ?
• Kann ich MQTT selbst implementieren ?
• Welche Vorteile entstehen durch den Einsatz von MQTT im Vergleich zur
bisherigen Kommunikation ?
4
2 Grundlagen
2.1 Was sind Telemetrie-Daten ?
Telemetrie beschreibt den Prozess des Übertragens von Messdaten von einem Sensor
zu einer bestimmten Stelle, an der diese gesammelt und gegebenenfalls auch ausge-
wertet werden. Diese Messdaten bezeichnet man unter anderem auch als Telemetrie-
Daten. Sie werden von Sensoren wie beispielsweise einem Temperatursensor erhoben.
Auch ein Mikrofon ist ein Sensor, der den Schallwechseldruck aufzeichnet. Beispiels-
weise wird in folgenden Bereichen Telemetrie eingesetzt:
• Datenübertragung in der Raumfahrt
• Aufzeichnen des Verhaltens von Tieren
• Überwachen von Patienten in der Medizin
• Datenerhebung in der Meteorologie
• Fahrzeugüberwachung im Motorsport
Da diese Daten ausschlieÿlich aus Messwerten bestehen, sind sie insbesondere auch
relativ klein. Aus diesem Grund gibt es Protokolle, die sich auf die Übertragung
der kleinen Daten spezialisiert haben, um auch über ein schlecht ausgebautes Netz
eektiv und zuverlässig kommunizieren zu können.
2.2 Machine-to-Machine-Kommunikation (M2M)
Machine-to-Machine-Kommunikation steht für den automatischen Daten uss zwi-
schen zwei Geräten und ist somit die Grundlage des Internets der Dinge. Um welche
Endgeräte es sich handelt oder wie eine Verbindung aufgebaut wird ist nicht vorge-
schrieben. Sie kommt in den unterschiedlichsten Gebieten unserer Gesellschaft zum
Einsatz und ndet vor allem vermehrt Anwendung in der Industrie. Ein neuer Be-
gri, der in diesem Zusammenhang in Deutschland immer öfter genannt wird, ist
Industrie 4.0. Dabei wird auf die kommende vierte industrielle Revolution verwie-
sen, in der die digitale Vernetzung und Automatisierung der Produktion durch das
Internet der Dinge im Mittelpunkt steht. [3] Maschinen sollen selbstständig mit-
einander kommunizieren und handeln. Das bekannteste Netzwerkprotokoll für die
Abwicklung einer M2M-Verbindung im Hinblick auf Telemetrie ist MQTT.
5
2.3 Kommunikationsarchitekturen und -muster im
Vergleich
Um ein Verständnis dafür zu bekommen, wie Computergesteuerte Geräte in der heu-
tigen, digital vernetzten Welt miteinander kommunizieren werden hier die Grundla-
gen geschaen.
2.3.1 Client/Server
Es gibt unterschiedliche Arten wie ein Nachrichtenaustausch oder Dienstleistungen
zwischen Geräten in Netzwerken realisiert werden können. Eine davon ist die Client-
Server-Architektur, die das Standardkonzept im Internet, in Unternehmensnetzwer-
ken sowie im Privatbereich ist. Beispielsweise werden folgende Protokolle oder auch
Anwendungen genannt ,die diese Architektur nutzen:
• Web
• FTP
• Telnet
• E-Mail
• MQTT
Wir de nieren einen Host, den sogenannten Server, der Daten und Dienste zur Ver-
fügung stellt. Hierbei könnte es sich um einen File- oder Webserver handeln. Dieser
nimmt Anfragen von weiteren Hosts entgegen, den sogenannten Clients, die bspw.
Daten von einem File- oder HTML-Code von einem Webserver anfordern. Als Bei-
spiel nehmen wir das Web als Anwendung, indem ein dauerhaft erreichbarer Webser-
ver die Anforderungen der Browser abarbeitet, die auf den Client-Rechnern laufen.
Der Client tätigt eine Anfrage an den Server für ein bestimmtes Objekt. Darauf-
hin antwortet der Webserver dem Client und schickt ihm das geforderte Objekt
zu. Hier ist schon das Request/Response-Verfahren zu erkennen, das im nächsten
Punkt ausführlicher erklärt wird. In der Client-Server-Architektur kommunizieren
die Clients nicht miteinander, genauso wenig die Server. Die Kommunikation ndet
nur zwischen Client und Server in eine Richtung statt. [4] Diese Architektur ist in
Abbildung 2.1 dargestellt.
6Abbildung 2.1: Client-Server-Architektur
Eine weitere Architektur, wäre die Peer-to-Peer (P2P) Architektur. Auf diese wird
aber nur kurz eingegangen, da sie im wesentlichen nichts mit MQTT zutun hat und
keine Verwendung ndet. Im Gegensatz zur Client-Server-Architektur können hier
die Hosts direkt miteinander kommunizieren, das heiÿt, dass eine Kommunikation
in beide Richtungen möglich ist. Eine direkte Kommunikation zwischen zwei Hosts,
die nicht ständig miteinander verbunden sind, wird auch als Peer bezeichnet. Bei-
spielsweise werden folgende Protokolle mit dieser Architektur betrieben:
7• Dateiaustausch (BitTorrent)
• Downloadbeschleunigung (Xunlei)
• Internettelefonie (Skype)
• IPTV
Siehe [5]
2.3.2 Request/Response
Nachdem in Punkt 2.3.1 die Architekturen vorgestellt wurden, beschäftigen sich die
nächsten zwei Unterpunkte mit den Kommunikationsmustern, die für den Austausch
von Nachrichten in Anwendungsprotokollen eingesetzt werden.
Um das Request/Response-Verfahren genauer zu verdeutlichen, verwenden wir an
dieser Stelle folgendes Beispiel:
• Abwicklung der Kommunikation zwischen Webclient, Webseite und Webserver
mittels HTTP-Protokoll.
Abbildung 2.2: Request/Response-Verfahren
Wie bereits in Punkt 2.3.1 beschrieben, wird auf einem Webserver, der permanent
online ist, eine Webseite gehostet. Möchte ein Client diese Seite abrufen, so schickt
sein Browser ein HTTP-Request (Anfrage) für die angeforderten Objekte auf dieser
Seite an den Server. Der Server antwortet mit einem HTTP-Response (Antwort),
welche den HTML-Code enthält. Anschlieÿend interpretiert der Webbrowser den
HTML-Code und zeigt die Seite an. [6]
82.3.3 Publish/Subscribe
Wie beim Request/Response-Verfahren nutzen die Clients einen zentralen Server,
den sogenannten Broker (Verteiler) für die Kommunikation. Untereinander kennen
sich die Clients nicht. Im Gegensatz zu HTTP muss man keinen Request tätigen
und auf das zugehörige Response warten, um eine Nachricht oder Objekte zu erhal-
ten. MQTT nutzt einen ereignisgesteuerten Ansatz, der mit den unten stehenden
Komponenten realisiert wird. [7]
Aufgaben des Brokers:
Wie bereits erwähnt, ist der Broker für die Verteilung oder auch Zuordnung der
Nachrichten zuständig. Er sorgt dafür, dass die von einem Client (Publisher) gesen-
deten Nachrichten, alle interessierten Clients (Subscriber) erreicht. [7]
Aufgaben des Subscribers:
Um überhaupt irgendeine Art von Nachrichten erhalten zu können, im Kontext
MQTT handelt es sich in der Regel um Sensordaten, muss sich der Client mit dem
Broker verbinden und ihm mitteilen, für welche Topics (Themen) er benachrichtigt
werden möchte. Dieser Vorgang wird als Subscribe (abonnieren oder vorbestellen)
bezeichnet. Der Subscriber könnte beispielsweise ein Nutzer sein, der auf seinem
Notebook die Temperaturdaten des Serverraums kontrollieren möchte. In Kapitel 4
(Installation) wird ein konkretes Beispiel gezeigt, wie die Nachrichten für den Client
angezeigt werden könnten. [7]
Aufgaben des Publishers:
Der Publisher erfasst Sensordaten und schickt sie anschlieÿend an den Broker. Zu-
sätzlich muss noch mitangegeben werden an welches Topic diese Nachricht geschickt
werden soll. Ein Publisher könnte beispielsweise ein Raspberry Pi mit angeschlosse-
nem Temperatur-, Feuchtigkeits-, oder Lichtsensor sein. [7]
An dieser Stelle ist schon ein wesentlicher Vorteil gegenüber HTTP zu erkennen.
Der Client, der Topics abonniert, wird automatisch darüber benachrichtigt, falls
neue Daten auf dem Broker vorliegen. Somit muss keine Anfrage gestartet werden,
um zu erfahren ob neue Daten vorhanden sind. [7]
9Abbildung 2.3: Publish/Subscribe-Verfahren
103 Funktionsweise MQTT
3.1 Einsatzbereiche
Bevor auf die Funktionsweise detaillierter eingegangen wird, werden zunächst einige
Beispiele genannt, wo MQTT Verwendung ndet. Ursprünglich war die Entwick-
lung des leichtgewichtigen Protokolls für die Überwachung von Ölpipelines über das
damals schwach ausgebaute Netz vorgesehen. Mittlerweile erönen sich jedoch viele
weitere Einsatzmöglichkeiten. Zwar ist MQTT noch relativ unbekannt und in sei-
nen Anfangsjahren, was die praktische Nutzung angeht, allerdings gibt es diverse
Projekte und bekannte Beispiele, in denen MQTT erfolgreich eingesetzt wird oder
werden kann:
• In einem 2007 umgesetzten Projekt von IBM mit dem Namen SiSi wurde
akustische Sprache in Zeichensprache konvertiert. Die Steuerung des Avatars
funktioniert hierbei über MQTT. [8]
• Die Facebook-Messenger-App für Smartphones benutzt für das Abrufen und
Versenden von Nachrichten MQTT. [9]
• Im Projekt FlootNet wird MQTT zum Überwachen von Flüssen eingesetzt.
[8]
• Könnte als Kontrolle für Administratoren verwendet werden (Bspw.: Überwa-
chung und Ermittlung der Innenwerte von Servern.
• M2M: Vernetzung von Maschinen in Produktionen (Maschinen müssten da-
durch nicht in das Unternehmensnetzwerk oder in ein Subnetz eingebunden
werden. Nur ein kleines Netzwerk mit Broker, Maschine und Client)
3.2 Beschreibung des Standards
Die aktuelle Version des Protokolls ist 3.1.1. Seit 2013 wird die Standardisierung von
MQTT, bei der Standardisierungsorganisation OASIS (Organisation for the Ad-
vancement of Structured Information Standards) durchgeführt. [10] Bei der
Beschreibung des Standards beschränken wir uns nur auf die wichtigsten Aspekte:
• Terminologie
• MQTT Kontrollpaket-Format (Aufbau eines MQTT Datenpakets)
• Sicherheit
113.2.1 Terminologie
Da im Grundlagenkapitel schon einige Begri ichkeiten wie Client oder Server be-
schrieben wurden, werden diese in diesem Kapitel nicht erneut aufgeführt.
Network Connection:
Ein Konstrukt, bereitgestellt durch das darunterliegende Transportprotokoll, das
von MQTT genutzt wird:
• Verbindet Client mit Server.
• Unterstützt das Senden von angeordneten, verlustfreien Datenströmen von
Bytes in beide Richtungen.
Siehe [11]
Application Message:
Die tatsächlichen Nutzdaten einer Anwendung, die mittels MQTT über das Netz-
werk verschickt werden. Angekommende Nachrichten sind mit einem QoS level und
einem Topic verknüpft. [11]
Topic Name:
Topics sind frei wählbare Strings und können mit einem Slash '/' aufgebaut und
erweitert werden. Ein Topic Name könnte folgendermaÿen aussehen:
home/CpuTemperature oder home/MemoryUsage . An der Stelle wäre home
das Root-Topic und die darauolgenden die Kind-Topics. Jeder Subscriber kann
frei wählen, welches Topic er abonnieren möchte. Möchte man alle Topics von Root
abonnieren, kann die Wildcard(#) benutzt werden (home/#). Ansonsten muss
das konkrete Kind-Topic mitangegeben werden (home/CpuTemperature). Sind
die Nachrichten des Publishers beim Broker angekommen, schickt er eine Kopie der
Nachrichten an jeden Client, der das zugehörige Topic hat. Bei den Topic-Namen ist
zu beachten, dass zwischen Groÿ- und Kleinschreibung unterschieden wird. [7] und
[11]
Topic Filter:
Ist ein Ausdruck, der in einem Abonnement enthalten ist, um Interessierten Clients
die Topics anzuzeigen. Ein Topic Filter kann Wildcards miteinbeziehen. [11]
Session:
Eine Interaktion zwischen Client und Server. Einige Sitzungen dauern nur so lange
an, wie die Netzwerkverbindungen, andere bauen hintereinander mehrere Netzwerk-
verbindungen zwischen Client und Server auf. [11]
MQTT Control Packet:
Ein Paket mit Informationen, welches über das Netzwerk versendet wird. MQTT de-
niert 14 verschiedene Typen von Kontrollpaketen, von denen eines (das PUBLISH
12Paket) zum Mitteilen von Nachrichten genutzt wird. [11]
QoS (Quality of Service Levels):
Für die Nachrichtenübermittlung de niert MQTT drei QoS-Levels.
Qos 0 (Höchstens einmal):
Diese Servicequalitätsstufe ist für das Übertragen von Sensordaten geeignet. Es kön-
nen Nachrichtenverluste statt nden. Die Nachricht kommt beim Empfänger höchs-
tens einmal an.
QoS 1 (Mindestens einmal):
Bei dieser Servicequalitätsstufe ist das Ankommen der Nachricht beim Empfänger
sichergestellt. Der Empfänger kann möglicherweise, die Nachricht mehrfach erhalten.
QoS 2 (Genau einmal):
Bei diesem Level wird sichergestellt, dass die Nachricht beim Empfänger genau ein-
mal ankommt. QoS 2 könnte für Geldtransaktionen oder ähnliches mir hoher Prio-
rität verwendet werden, da die Nachrichten nicht mehrfach beim Empfänger an-
kommen und auch nicht verloren gehen. Doppelte Geldtransaktionen könnten fatale
Folgen haben.
Siehe [7]
3.2.2 MQTT Kontroll Paket Format
Unter MQTT werden Kontrollpakete (Control Packets) auch als Datenpakete oder
Pakete bezeichnet. Die Arbeitsweise dieses Protokolls erfolgt durch das Austauschen
einer Folge von Kontrollpaketen in einer de nierten Richtung. Die Struktur eines
Paketes besteht aus drei Teilen und ist immer in dieser Reihenfolge aufgebaut. Die
Struktur ist in der Tabelle 3.1 dargestellt.
Fixed header, in jedem MQTT Kontrollpaket enthalten
Variable header, in manchen MQTT Kontrollpaketen enthalten
Payload, in manchen MQTT Kontrollpaketen enthalten
Tabelle 3.1: Aufbau MQTT Kontrollpaket
Siehe [12]
13Fixed header
Wie bereits erwähnt besitzt jedes Kontrollpaket einen Fixed header. Tabelle 3.2
zeigt den Aufbau des Fixed headers.
Bit 7 6 5 4 3 2 1 0
byte 1 Typ des Kontrollpakets Flags
byte 2 Restliche Paketlänge
Tabelle 3.2: Aufbau: Fixed header
Der Fixed header beinhaltet folgende Informationen:
• Bit sieben bis vier de nieren den Nachrichtentyp (siehe Tabelle 3.3). [13]
• Bit drei bis null repräsentieren Flags. Welche Informationen die Flags beschrei-
ben, wird auf Seite 15 erklärt.
• Die Restliche Paketlänge.
Siehe [14]
Name Wert Flussrichtung Beschreibung
Reserviert 0 Verboten Reserviert
CONNECT 1 Client zu Server Client request um mit Server zu verbin-
den
CONNACK 2 Server zu Client Connect acknowledgement
PUBLISH 3 Client zu Server oder Publish Nachricht
Server zu Client
PUBACK 4 Client zu Server oder Publish acknowledgement
Server zu Client
PUBREC 5 Client zu Server oder Publish received (QoS 2, Teil 1)
Server zu Client
PUBREL 6 Client zu Server oder Publish release (QoS 2, Teil 2)
Server zu Client
PUBCOMP 7 Client zu Server oder Publish complete (QoS 2, Teil 3)
Server zu Client
SUBSCRIBE 8 Client zu Server Client subscribe request
SUBACK 9 Server zu Client Subscribe acknowledgement
UNSUBSCRIBE 10 Client zu Server Unsubscribe request
UNSUBACK 11 Server zu Client Unsubscribe acknowledgement
PINGREQ 12 Client zu Server PING Request
PINGRESP 13 Server zu Client PING Response
DISCONNECT 14 Client zu Server Client beendet Verbindung
Reserviert 15 Verboten Reserviert
Tabelle 3.3: MQTT Kontrollpaket-Typen
14Anhand eines Beispiels soll gezeigt werden wie der Fixed header bei dem Nach-
richtentyp (Control Packet type) PUBLISH aussieht, welcher für die Übertragung
von Nutzdaten zuständig ist. In diesem Beispiel gehen wir davon aus, dass zwischen
Client und Broker mittels den Kontrollpakettypen CONNECT und CONNEC-
TACK eine Verbindung hergestellt wurde.
Bit 7 6 5 4 3 2 1 0
byte 1 Typ des Kontrollpakets (3) DUP QoS level RETAIN
ag
0 0 1 1 X X X X
byte 2 Restliche Paketlänge
Tabelle 3.4: PUBLISH-Paket
Siehe [15]
DUP ag:
Dieses Flag ist auf 1 gesetzt, wenn Client oder Server versuchen, eine PUBLISH-
Nachricht zurück zu schicken. Für alle Nachrichten mit dem QoS level 0 muss das
DUP ag auf 0 gesetzt sein. [15]
QoS level:
Mit diesem Flag wird die Priorität festgelegt, mit welcher die Nachrichten verschickt
werden sollen. Die QoS levels wurden im Punkt 3.2.1 Terminologie beschrieben.
RETAIN:
Sendet der Client ein PUBLISH-Paket, indem das RETAIN Flag auf 1 gesetzt ist,
muss der Broker die Nachricht und den QoS level speichern, damit es in Zukunft an
Subscriber geschickt werden kann, deren Topic Name mit dem Abonnement über-
einstimmt. [15]
Restliche Paketlänge:
Dieses Byte repräsentiert die verbleibende Länge innerhalb des aktuellen Pakets,
einschlieÿlich dem Variable header und dem Payload. [16]
Variable header:
Der Variable header besteht aus folgenden Feldern in gegebener Reihenfolge: Topic
Name und Paket Identi er. [17]
Payload:
Das Payload beinhaltet die Nutzdaten, die via PUBLISH vermittelt werden. Der
Inhalt und das Format sind spezi sch. Die Länge des Payloads lässt sich durch eine
Subtraktion von Variable header - Restliche Paketlänge errechnen. [18]
153.2.3 Sicherheit
Wie andere Protokolle bietet auch MQTT Sicherheitsfeatures, um die Kommuni-
kation zwischen Client und Server sicherer zu gestalten. Zusätzlich wird unter die-
sem Punkt auch beschrieben, welche bestehenden Sicherheitstechnologien eingesetzt
werden können, um die Vertraulichkeit zwischen den Kommunikationspartnern zu
gewährleisten.
Authenti kation der Clients am Server
MQTT stellt einen Authenti kationsmechanismus bereit, indem, innerhalb eines
CONNECT-Pakets Felder wie Username und Password enthalten sind. Bei der
Entwicklung einer Anwendung, die MQTT nutzt, kann selbst entschieden werden, ob
dieser bereitgestellte Mechanismus genutzt wird, oder ob auf externe Sicherheitsme-
chanismen, wie bspw.: LDAP oder Betriebssysteminterne Mechanismen, zugegrien
wird.
Diesen Mechanismus zu nutzen reicht allein nicht aus, da beim Verbindungsaufbau
Username und Password in Klartext übermittelt werden. Wird TLS verwendet, sen-
den die Clients SSL-Zerti kate an den Server, der authenti ziert sie anhand der
gültigen Zerti kate.
• Eine VPN-Verbindung (Virtual Private Network) zwischen Clients und Ser-
vern schat weitere Vertraulichkeit, indem nur Daten von autorisierten Clients
empfangen werden.
• Die Authenti kation eines Servers am Client wird ebenfalls durch TLS mit
dem Einsatz von SSL- Zerti katen realisiert.
Siehe [19]
Autorisierung der Clients am Server
Der Zugri auf Serverressourcen (bspw.: die Topics des Brokers) können durch
falsche Informationen der Clients eingeschränkt werden:
• Username
• Client Identi er
• Hostname / IP-Adresse
• Resultat der Authenti zierung
Siehe [20]
163.3 Einordnung des MQTT-Protokolls
Um einen besseren Überblick über die Netzwerkkommunikation des MQTT-Protokolls
zu erhalten, wird nachfolgend kurz beschrieben, wie es unter den Netzwerkprotokoll-
Schichten eingeordnet ist. MQTT an sich ist ein Anwendungsprotokoll. Als ein sol-
ches nutzt es ein Protokoll aus der Transportschicht. Da MQTT eine feste Verbin-
dung zwischen den Clients und dem Server über das Internet erfordert, wird das TCP
verwendet. Folgendes Bild des Onlineportals heise.de zeigt eine solche Einordnung.
[21]
Abbildung 3.1: MQTT im TCP-Stack
3.4 MQTT for Sensor Networks
Message Queue Telementry Transport for Sensor Networks (MQTT-SN) ist eine Va-
riante des Protokolls MQTT, das sich auf drahtlose Sensornetzwerke spezialisiert,
wodurch Anpassungen aufgrund von möglichen Unterbrechungen, geringerer Band-
breite und kleineren Nachrichtengröÿen nötig sind. Folgende Komponenten dienen
zur Realisierung eines solchen Netzwerks: [22, S. 5-6]
Abbildung 3.2: MQTT-SN Komponenten
17Client:
Bei den MQTT-SN Clients handelt es sich, wie bei MQTT, um Sensoren, die ihre
Daten an einen Broker übermitteln. Die Besonderheit besteht darin, dass die Mo-
dule kabellos über MQTT-SN mit einem Gateway verbunden sind.
Gateway:
Wie bereits erwähnt, sind die Sensor-Clients mit dem MQTT-SN Gateway verbun-
den. Sofern in diesem kein Broker enthalten ist, werden die erhaltenen Daten an
einen solchen über MQTT weitergeleitet. Man kann das Gateway auf zwei unter-
schiedliche Arten betreiben. Ein Transparent Gateway baut für jeden MQTT-SN
Client eine eigene MQTT Verbindung mit dem Broker auf. Das Aggregating Ga-
teway hingegen sammelt die Daten der Clients und entscheidet, welche davon an
den Broker weitergeleitet werden sollen. Letzteres mag zwar in Hinsicht auf ein um-
fangreiches Sensor-Netzwerk vorteilhaft erscheinen, da nicht mehrere Verbindungen
gleichzeitig bearbeitet werden müssen, ist jedoch aber auch aufwändiger zu imple-
mentieren.
Abbildung 3.3: MQTT-SN Gateways
Forwarder:
Ist ein Gateway von einem Sensor-Client aus nicht direkt erreichbar, so kann über
einen MQTT-SN Forwarder eine Verbindung zu diesem aufgebaut werden. Die Da-
ten werden somit unverändert an das Gateway übermittelt. Umgekehrt ist es auch
möglich, Daten an den Forwarder zu senden, der diese wiederum den Clients über-
gibt.
Vergleicht man MQTT-SN mit MQTT, so lassen sich unter anderen folgende Haupt-
unterschiede erkennen. [22, S. 4-5]
• MQTT-SN Verbindungen basieren nicht auf TCP, sondern werden über kabel-
lose Netzwerke wie Zigbee realisiert.
• Um der geringeren Bandbreite gerecht zu werden, verwendet man für das to-
pic der Publish-Nachricht anstatt Namen topic ids. Diese sind entweder vor-
de niert oder werden nach einem Registratrionsverfahren auf dem Gateway
hinterlegt.
18• Kurze topic names sind zwei Byte groÿ und neben der topic id ebenfalls erlaubt.
• Über eine Suchfunktion können Clients ohne festgelegtes Gateway automatisch
ein solches nden.
• Da batteriebetriebene Systeme gelegentlich o ine sind, ist ein keep-alive-Verfahren
nötig. Dadurch werden Nachrichten an einen schlafenden Client im Gateway
vermerkt und automatisch an diesen weitergeleitet, sobald er wieder online ist.
3.5 Vergleich mit anderen Protokollen
Obwohl jedes Anwendungsprotokoll seinen eigenen thematischen Schwerpunkt hat,
bietet sich ein Vergleich zwischen diesen an, um zu erfahren, welche Kombination
von Funktionen ein Protokoll benötigt, sodass dessen Zweck erfüllt werden kann.
Dadurch lassen sich sowohl Unterschiede als auch Gemeinsamkeiten feststellen. Die
Nachfolgende Tabelle zeigt einen Vergleich zwischen allgemein bekannten Anwen-
dungsprotokollen inklusive MQTT. [21]
Protokoll MQTT CoAP FTP HTTP/1.1 HTTP/2
Transport TCP UDP TCP TCP TCP
Session x x x
Request/Response x x x x
Client/Server x x x x x
Publish/Subscribe x x push
Message Broker x
Message Data binary binary text text binary
Tabelle 3.5: Vergleich von Anwendungsprotokollen
194 Installation
Nachdem die Funktionsweise des MQTT-Protokolls detailliert erklärt wurde und so-
mit bekannt ist, widmet sich dieses Kapitel der Installation und Kon guration von
MQTT.
Die Eclipse Foundation leitete Anfang 2012 das Paho-Projekt. Das Ziel bestand dar-
in, eine Open-Source-Implementierung für M2M-Protokolle bereitzustellen. MQTT
existiert schon seit 1999, entwickelt durch IBM und Eurotech, welche auch die Initia-
limplementierung bereitgestellt haben. Die Referenzimplementierung des MQTT-
Protokolls kann für Clients (Publisher und Subscriber) in mehreren Programmier-
sprachen realisiert werden, bspw.: Java, C, C++, Python und JavaScript. [7]
In den nächsten Punkten wird gezeigt, wie die erste 'IoT-Anwendung' geschrieben
werden kann.
4.1 Beschreibung
Bekannt ist, dass MQTT einen geringen Protokoll-Overhead hat und somit für
breitbandschonende Kommunikation geeignet ist. In folgendem Beispiel wird ein
Raspberry Pi benutzt, aus diesem werden die CPU-Temperatur und die Ar-
beitsspeichernutzung ausgelesen, wobei es sich bei letzterem nicht um Sensorda-
ten handelt, aber dennoch geringe Datenmengen sind. Das Auslesen und versenden
der Daten wird mit einer Java-Implementierung realisiert. Das Raspberry Pi hat In-
ternetzugri und übernimmt die Rolle des Publishers. Die ermittelten Sensordaten
werden an einen öentlichen Broker geschickt. Der Subscriber, ein weiteres Gerät,
abonniert die CPU-Temperatur und Arbeitsspeichernutzung. Sobald die Daten beim
Broker angekommen sind, leitet dieser diese an den Subscriber weiter. Abbildung
4.1 - Beispiel.
Abbildung 4.1: Beispiel
204.2 Komponenten
Publisher:
Zum Einsatz kam ein Raspberry Pi 1 Model B mit einer SDHC-Karte (8 GB). Als
Betriebssystem wurde die Distribution Raspbian, die auf Debian basiert, genutzt.
Wie das Betriebssystem auf dem Raspberry Pi zu installieren ist, wird auf folgender
Seite ausführlich beschrieben:
https://www.raspberrypi.org/documentation/installation/installing-images/.
Um Java Programme kompilieren und ausführen zu können, muss das openjdk in-
stalliert werden, dass die Java-Plattform bereitstellt. Unter Linux geschieht das mit
folgendem Befehl: sudo apt-get install openjdk-7-jdk.
Broker:
Für den Austausch der Sensordaten wurde das öentliche MQTT-Dashboard
(http://mqtt-dashboard.com/dashboard) benutzt, welches von der Firma dc-
square für Testzwecke bereitgestellt wurde. Damit der Publisher Daten an diesen
Broker schicken kann, werden folgende Informationen benötigt:
• Broker: broker.mqttdashboard.com
• Port: 1883
Subscriber:
Der Subscriber wurde als Webdashboard mittels HTML und JavaScript umgesetzt.
Die empfangenen Daten werden in Diagrammen gra sch dargestellt. Zusätzlich wird
angezeigt, ob der Publisher momentan On- oder O ine ist. In der unten stehen-
den Aufzählung wird beschrieben, welche JavaScript-Bibliotheken benötigt wer-
den, um den Subscriber zu implementieren. Editoren wie Notepad++ oder JS-
Designer werden ebenfalls benötigt, um die Java-Skripte zu erstellen.
• Eclipse Paho Bibliothek, die MQTT über Websockets im Browser implemen-
tiert. (https:// eclipse.org/paho/clients/js/)
• Bootstrap Framework, dass Komponenten und gra sche Elemente bereitstellt.
(http:// getbootstrap.com/)
• jQuery, beinhaltet Tools für JavaScript. (http://jquery.com/download/)
• JustGage, stellt Diagramme bereit. (http://justgage.com/)
214.3 Implementierung
Der Unterpunkt Implementierung beschränkt sich auf die wichtigsten Codefrag-
mente des Publishers und Subscribers. Hierbei handelt es sich um eine modi zierte
Version, die wir für unser Beispiel angepasst haben. Diese ist auf Bitbucket [23] ver-
fügbar. Der Originalquellcode ist auf GitHub [24] verfügbar.
Publisher:
1 import o r g . e c l i p s e . paho . c l i e n t . mqttv3 . ∗ ;
2 import com . p i 4 j . system . S y s t e m I n f o ;
Listing 4.1: Einbindung der benötigten Bibliotheken
Der Sensorclient benötigt wie der Subscriber die Eclipse Paho Bibliothek, jedoch kei-
ne JavaScript- sondern eine Java Bibliothek. Damit die CPU-Temperatur und die
Arbeitsspeichernutzung ermittelt werden kann, muss noch eine weitere Bibliothek
eingebunden werden, die in Zeile 2 vorhanden ist. Diese ist auf GitHub verfügbar.
(https://github.com/Pi4J/pi4j/tree/develop)
1 // O b j e k t V a r i a b l e n
2 p r i v a t e MqttClient c l i e n t ;
3 p u b l i c s t a t i c f i n a l S t r i n g BROKER_URL = " t c p : / / b r o k e r . mqttdashboard . com
:1883 " ;
4
5 public s t a t i c f i n a l S t r i n g TOPIC_CPU_TEMPERATURE = "home/ c p u t e m p e r a t u r e
";
6 public s t a t i c f i n a l S t r i n g TOPIC_MEMORY_USED = "home/memoryused" ;
7 public s t a t i c f i n a l S t r i n g TOPIC_MEMORY_FREE = "home/ memoryfree " ;
8 public s t a t i c f i n a l i n t mb = 1024 ∗ 1 0 2 4 ;
Listing 4.2: Deklaration der Variablen
Die Variable client wird benötigt, damit der Konstruktor später eine Instanz der
Klasse MqttClient erzeugen kann. Die BROKER_URL de niert die Adresse des
Brokers als String. Die restlichen Strings stellen die Topics dar. Der Integer mb
wandelt die ermittelte Arbeitsspeichernutzung in die richtige Einheit um.
1 public Publisher () {
2 S t r i n g c l i e n t I d = U t i l s . getMacAddress ( ) + "−pub" ;
3 try {
4 // I n s t a n z der Klasse MqttClient erzeugen .
5 c l i e n t = new M q t t C l i e n t (BROKER_URL, c l i e n t I d ) ;
6 } c a t c h ( MqttException e ) {
7 e . printStackTrace () ;
8 System . e x i t ( 1 ) ;
9 }
10 }
Listing 4.3: MqttClient-Objekt erzeugen
22Der Konstruktor erhält als Parameter die Adresse des Brokers und eine eindeutige
Client-ID. Diese setzt sich aus der MAC-Adresse des Rechners und einem String -pub
zusammen. Der MQTT-Broker unterstützt nur eine ID pro Client. Verbindet sich ein
zweiter, mit derselben ID, so bricht der Broker die Verbindung des älteren Clients ab.
1 p r i v a t e v o i d s t a r t ( ) throws NumberFormatException , IOException {
2 try {
3 MqttConnectOptions o p t i o n s = new MqttConnectOptions ( ) ;
4 options . setCleanSession ( f a l s e ) ;
5 o p t i o n s . s e t W i l l ( c l i e n t . g e t T o p i c ( "home/ s t a t u s " ) , " o f f l i n e " . g e t B y t e s
() , 1 , true ) ;
6 c l i e n t . connect ( options ) ;
7 c l i e n t . p u b l i s h ( "home/ s t a t u s " , " o n l i n e " . g e t B y t e s ( ) , 1 , t r u e ) ;
8
9 // P u b l i s h data
10 while ( true ) {
11 publishCpuTemperature ( ) ;
12 Thread . s l e e p ( 5 0 0 ) ;
13 publishMemoryUsed ( ) ;
14 Thread . s l e e p ( 5 0 0 ) ;
15 publishMemoryFree ( ) ;
16 Thread . s l e e p ( 5 0 0 ) ;
17 }
18 } c a t c h ( MqttException e ) {
19 e . printStackTrace () ;
20 System . e x i t ( 1 ) ;
21 } catch ( InterruptedException e ) {
22 e . printStackTrace () ;
23 }
24 }
Listing 4.4: start-Funktion
Als nächstes wird eine Instanz der Klasse MqttOptions erzeugt, damit beim Ver-
bindungsaufbau zum Broker mittels der connect -Methode diverse Eigenschaften in
options festgelegt werden können. Ist setCleanSession auf false gesetzt, wird dem
Broker mitgeteilt, dass mit einer alten Sitzung gearbeitet werden soll, falls der Client
schon einmal mit diesem Broker verbunden war.
Eine RETAINED MESSAGE wie in Zeile 5, gesetzt durch das true , ermöglicht
es dem Subscriber (Webdashboard), die zuletzt versendeten Werte pro Topic an-
zuzeigen, auch wenn der Publisher o ine ist. An dieser Stelle wird das QoS level
1 verwendet, damit sichergestellt ist, dass die Sensordaten ein- oder mehrfach an-
kommen. In diesem Szenario sieht der Kommunikationsablauf zwischen Publisher,
Broker und Subscriber folgendermaÿen aus:
• Beim Start des Publishers wird sein letzer Wille an das Topic home/status
mit der Nachricht o ine an den Broker übergeben.
• War der Verbindungsaufbau erfolgreich, wird die Nachricht online an das
Topic home/status gesendet.
23• Anschlieÿend werden Sensordaten an die Topics
home/cputemperature
home/memoryused
home/memoryfree gesendet.
• Wird die Verbindung unterbrochen, so schickt der Publisher an den Broker die
Nachricht o ine in das Topic home/status . Der Subscriber (Webdashboard)
ist somit informiert, dass der Publisher nicht mehr verbunden ist.
Anschlieÿend wird eine Endlosschleife durchgeführt, in der Methoden für die Er-
mittlung der CPU-Temperatur, des genutzten Arbeitsspeichers und des frei-
en Arbeitsspeichers aufgerufen, und an den Broker geschickt werden. Auf die
Methoden für die Ermittlung der Sensordaten wird nicht näher eingegangen, diese
be nden sich auf GitHub.
https://github.com/goetzchr/webdashboard-with-mqtt/tree/master/sensor-
client/src/main/java/de/dcsquare/paho/client/publisher.
Wurden die restlichen Codefragmente übernommen, muss aus dem Quelltext noch
eine ausführbare Jar-Datei erstellt werden, damit diese auf dem Raspberry Pi aus-
geführt werden kann. Mit dem Befehl java -jar Publisher.java wird der Publisher
gestartet und mit Strg + C beendet.
Abbildung 4.2: Publisher wird ausgeführt
24Subsrciber:
1
2
3 MQTT L i v e Dashboard
4 < s c r i p t s r c=" a s s e t s / j s / j q u e r y . j s ">
5 < s c r i p t s r c=" l i b / b o o t s t r a p / j s / b o o t s t r a p . min . j s ">
6 < s c r i p t s r c=" l i b / j u s t g a g e / r a p h a e l . 2 . 1 . 0 . min . j s ">
7 < s c r i p t s r c=" l i b / j u s t g a g e / j u s t g a g e . 1 . 0 . 1 . min . j s ">
8 < s c r i p t s r c=" l i b / paho / paho . j s ">
9 < s c r i p t s r c=" j s /app . j s ">
10
11
Listing 4.5: Einbindung der benötigten Bibliotheken
Damit die ermittelten Sensordaten empfangen und gra sch dargestellt werden kön-
nen, muss zunächst eine HTML-Datei erstellt werden, in der die JavaScript-Bibliotheken
eingebunden werden. Diese wurden im Punkt 4.2 Subscriber genannt. Die Einbin-
dung der app.js in Zeile 9 beschreibt die eigentliche Funktionalität des Subscribers.
1 var c l i e n t = new Messaging . C l i e n t ( " b r o k e r . mqttdashboard . com" , 8 0 0 0 , "
dashboard " ) ;
2 var cputemp ;
3 var usedmem ;
4 var freemem ;
Listing 4.6: Variablen - app.js
Zeile 1 wird benötigt um den Broker zu de nieren, von dem man Nachrichten erhal-
ten möchte. An dieser Stelle kann auch eine IP-Adresse eingetragen werden, falls
man einen eigenen Broker im lokalen Netzwerk betreibt. Die Variablen in den Zeilen
2 bis 4 werden für das Speichern der erhaltenen Werte verwendet.
1 var c l i e n t = new Messaging . C l i e n t ( " b r o k e r . mqttdashboard . com" , 8 0 0 0 , "
dashboard " ) ;
2 $ ( document ) . ready ( f u n c t i o n ( ) {
3
4 var o p t i o n s = {
5
6 // T i m e o u t
7 timeout : 3 ,
8
9 // V e r b i n d u n g s a u f b a u erfolgreich .
10 onSuccess : function () {
11
12 client . s u b s c r i b e ( "home/ s t a t u s " ) ;
13 client . s u b s c r i b e ( "home/ memoryfree " ) ;
14 client . s u b s c r i b e ( "home/ c p u t e m p e r a t u r e " ) ;
15 client . s u b s c r i b e ( "home/memoryused" ) ;
16 },
17
2518 // V e r b i n d u n g s a u f b a u nicht erfolgreich .
19 o n F a i l u r e : f u n c t i o n ( message ) {
20
21 a l e r t ( " Connection f a i l e d : " + message . e r r o r M e s s a g e ) ;
22 }
23 };
Listing 4.7: Topic-Subscription
Dieses Codefragment beschreibt die Abonnierung der Topics bei erfolgreichem Ver-
bindungsaufbau. War der Verbindungsaufbau nicht erfolgreich, wird die onFailure -
Funktion aufgerufen.
1 // A u f r u f bei Nachrichtenempfang .
2 c l i e n t . onMessageArrived = f u n c t i o n ( message ) {
3
4 var t o p i c = message . d e s t i n a t i o n N a m e ;
5
6 i f ( t o p i c === "home/ s t a t u s " ) {
7
8 i f ( message . p a y l o a d S t r i n g === " o f f l i n e " ) {
9 $ ( "#c l i e n t _ d i s c o n n e c t e d " ) . html ( ' Raspberry Pi P u b l i s h e r O f f l i n e ' ) .
removeClass ( " h i d e " ) . h i d e ( ) . f a d e I n ( " s l o w " ) ;
10 $ ( "#c l i e n t _ c o n n e c t e d " ) . a d d C l a s s ( " h i d e " ) . h i d e ( ) ;
11 } else {
12 $ ( "#c l i e n t _ c o n n e c t e d " ) . html ( ' Raspberry Pi P u b l i s h e r O n l i n e ' ) .
removeClass ( " h i d e " ) . h i d e ( ) . f a d e I n ( " s l o w " ) ;
13 $ ( "#c l i e n t _ d i s c o n n e c t e d " ) . a d d C l a s s ( " h i d e " ) . h i d e ( ) ;
14 }
15 }
16 e l s e i f ( t o p i c === "home/ c p u t e m p e r a t u r e " ) {
17 setCPU ( message . p a y l o a d S t r i n g ) ;
18 }
19 e l s e i f ( t o p i c === "home/memoryused" ) {
20 setMEMU( message . p a y l o a d S t r i n g ) ;
21 }
22 e l s e i f ( t o p i c === "home/ memoryfree " ) {
23 setMEMF( message . p a y l o a d S t r i n g ) ;
24 }
25 };
Listing 4.8: Topic-Subscription
Werden Nachrichten empfangen, wird im Variable header des Pakets geprüft, in
welches Topic die Daten gehören. Mit dem Befehl client.connect(options) erfolgt der
Verbindungsaufbau zum Broker. In Abbildung 4.3 ist das Webdashboard des Subs-
cribers dargestellt.
26Abbildung 4.3: Subscriber - Webdashboard
275 Evaluierung
Durch die kurze Einführung in das Internet der Dinge wurde ein erster Eindruck
über die Einsatzmöglichkeiten von M2M-Protokollen wie MQTT vermittelt. Ebenso
konnten grundlegende Fragen über das Aufzeigen unterschiedlicher Kommunikati-
onsmuster geklärt werden. Diese hielten wir für besonders wichtig, damit der Leser
die Vorteile von MQTT erkennt und versteht warum von einem leichtgewichtigem
Protokoll die Rede ist. Durch die kurzgefasste Erarbeitung der Grundlagen kann
dies erreicht werden.
Mit Hilfe der Spezi kation von MQTT.org und der bereitgestellten Kindle-Version
von entwickler.press über MQTT im IoT - Einstieg in die M2M-Kommunikation
konnte ein tiefer Einblick in den Aufbau und die Funktionsweise geworfen werden.
Diese zwei Quellen wurden auch als Hauptquellen für diese Ausarbeitung genutzt.
Bei der Recherche zur Literatur ndung wurden zahlreiche Artikelserien und Beiträ-
ge gefunden, deren Inhalte jedoch fast identisch und somit unbrauchbar waren. An
dieser Stelle möchten wir den zweiten Teil der Artikelserie 'Anweundungsprotokol-
le im Vergleich - Gegenüberstellung' von Maik Woijcieszak besonders hervorheben.
Dieser Beitrag hat uns sehr geholfen, da zu Beginn noch Klärungsbedarf bestand, ob
das MQTT-Protokoll auf der Transport- oder Anwendungsschicht des TCP-Modells
angesiedelt ist.
Zusammenfassend konnten fast alle zuvor de nierten Deadlines zur Ausfertigung die-
ser Arbeit erfolgreich eingehalten werden. Die Anpassung der Referenzimplementie-
rung für unser eigenes Beispiel in Kapitel 4 hatte mehr Zeit in Anspruch genommen
als geplant. Ursprünglich sollte noch ein lokaler Broker im eigenen Netz installiert
und kon guriert werden, doch aus Zeitgründen wurde ein öentlicher Broker im
Internet genutzt.
286 Fazit und Ausblick
Wenn man nun das Thema nochmals Revue passieren lässt, so kristallisieren sich
die Vorteile von MQTT schnell heraus. Es ist in der Tat ein geeignetes Nachrich-
tenprotokoll, was den M2M Datenverkehr über kurze Nachrichten angeht. Durch
die Priorisierung von Datenpaketen mit den QoS levels, lässt sich das Protokoll in-
dividuell auf die jeweilige Situation einstellen. Ein kompakter Header sorgt dafür,
dass Datenpakete auch bei stark begrenzter Bandbreite schnell und zuverlässig über-
mittelt werden. MQTT hat ein enormes Potential, die Community wächst und es
sind zahlreiche Bastlerprojekt im Internet aufzu nden. Kommerziell gesehen ist der
Bekanntheitsgrad noch sehr gering, daher ndet MQTT nur begrenzt Verwendung.
Ebenso lässt sich neben den zahlreichen Internetquellen kaum Literatur über das
Protokoll nden, wodurch man auch erkennen kann, dass sich dieses Protokoll noch
in den Startlöchern be ndet. Mit Sicherheit kann man davon ausgehen, dass der
Bekanntheitsgrad von MQTT im Laufe der nächsten Jahre über die zunehmende
Relevanz des Internets der Dinge ebenfalls ansteigen wird.
29Abbildungsverzeichnis
2.1 Client-Server-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Request/Response-Verfahren . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Publish/Subscribe-Verfahren . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 Einordnung von MQTT . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Verbindung zwischen MQTT-SN Komponenten . . . . . . . . . . . . 17
3.3 Unterschiede von MQTT-SN Gateways . . . . . . . . . . . . . . . . . 18
4.1 Installationsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Ausführung des Publishers in einem LXTerminal . . . . . . . . . . . . 24
4.3 Subscriber wird ausgeführt . . . . . . . . . . . . . . . . . . . . . . . . 27
30Tabellenverzeichnis
3.1 Aufbau MQTT Kontrollpaket . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Aufbau: Fixed header . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 MQTT Kontrollpaket-Typen . . . . . . . . . . . . . . . . . . . . . . . 14
3.4 PUBLISH-Paket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 Vergleich von Anwendungsprotokollen . . . . . . . . . . . . . . . . . . 19
31Listings
4.1 Einbindung der benötigten Bibliotheken . . . . . . . . . . . . . . . . 22
4.2 Deklaration der Variablen . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3 MqttClient-Objekt erzeugen . . . . . . . . . . . . . . . . . . . . . . . 22
4.4 start-Funktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5 Einbindung der benötigten Bibliotheken . . . . . . . . . . . . . . . . 25
4.6 Variablen - app.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.7 Topic-Subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.8 Topic-Subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
32Literaturverzeichnis
[1] Frequently asked questions. Internet: http://mqtt.org/faq, visited
03.06.2015.
[2] The internet of things enables digital business. Internet: http://www.gartner.
com/technology/research/internet-of-things/, visited 23.05.2015.
[3] Zukunftsprojekt industrie 4.0. Internet: http://www.bmbf.de/de/9072.php,
visited 23.05.2015.
[4] James Kurose and Keith Ross. Computernetzwerke - Der Top-Down-Ansatz,
chapter Architektur von Netzwerkanwendungen, pages 110111. Pearson Edu-
cation Inc., 6., updt. edition.
[5] James Kurose and Keith Ross. Computernetzwerke - Der Top-Down-Ansatz,
chapter Architektur von Netzwerkanwendungen, pages 123124. Pearson Edu-
cation Inc., 6., updt. edition.
[6] James Kurose and Keith Ross. Computernetzwerke - Der Top-Down-Ansatz,
chapter Überblick über HTTP, pages 111112. Pearson Education Inc., 6.,
updt. edition.
[7] Dominik Obermaier, Christian Götz, Klemens Edler, and Florian Pirchner.
MQTT im IoT - Einstieg in die M2M-Kommunikation. entwickler.press, 2014.
chapter 1 M2M-Kommunikation mit MQTT. [Kindle-Edition].
[8] Projects. Internet: http://mqtt.org/projects, visited 03.06.2015.
[9] Lucy Zhang. Building facebook messenger. Internet: https://www.facebook.
com/notes/facebook-engineering/building-facebook-messenger/
10150259350998920, visited 26.05.2015.
[10] Andrew Banks and Rahul Gupta. Oasis standard. Internet:
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.
html#_Toc398718008, visited 29.05.2015.
[11] Andrew Banks and Rahul Gupta. Terminology. Internet: http:
//docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#
_Toc398718010, visited 29.05.2015.
[12] Andrew Banks and Rahul Gupta. Structure of an mqtt control packet format.
Internet: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.
1-os.html#_MQTT_Control_Packet, visited 30.05.2015.
33[13] Andrew Banks and Rahul Gupta. Mqtt control packet type. Internet:
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.
html#_Toc398718021, visited 31.05.2015.
[14] Andrew Banks and Rahul Gupta. Fixed header. Internet: http:
//docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#
_Toc398718020, visited 31.05.2015.
[15] Andrew Banks and Rahul Gupta. Publish message. Internet:
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.
html#_Toc398718037, visited 31.05.2015.
[16] Andrew Banks and Rahul Gupta. Remaining length. Internet:
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.
html#_Toc398718023, visited 04.06.2015.
[17] Andrew Banks and Rahul Gupta. Variable header. Internet:
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.
html#_Toc398718039, visited 04.06.2015.
[18] Andrew Banks and Rahul Gupta. Payload. http:
Internet:
//docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#
_Toc398718040, visited 04.06.2015.
[19] Andrew Banks and Rahul Gupta. Authenti cation of clients by the server.
Internet: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.
1-os.html#_Toc398718116, visited 07.07.2015.
[20] Andrew Banks and Rahul Gupta. Authorization of clients by the server.
Internet: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.
1-os.html#_Toc398718117, visited 07.07.2015.
[21] Maik Wojcieszak. Internet-protokolle, teil 2: Anwendungsprotokol-
le im vergleich. Internet: http://www.heise.de/developer/artikel/
Internet-Protokolle-Teil-2-Anwendungsprotokolle-im-Vergleich-2632571.
html?artikelseite=3, visited 25.05.2015.
[22] Andy Stanford-Clark und Hong Linh. Mqtt for sensor networks (mqtt-sn) - pro-
tocol speci cation version 1.2. Internet: http://mqtt.org/new/wp-content/
uploads/2009/06/MQTT-SN_spec_v1.2.pdf, visited 25.05.2015.
[23] Modi ed sourcecode for publisher and subscriber. Internet: https://
bitbucket.org/masterblaster1/mqtt/src,.
[24] Original sourcecode for publisher and subscriber. Internet: https://github.
com/goetzchr/webdashboard-with-mqtt,.
34Sie können auch lesen
