Web- und Netzwerktechnologie

• unidirektional, synchron, stateless

• one-to-one

• internet-tauglich

• sicher; mittels TLS

• plattformunabhängig; Java, JavaScript, C++, ...

keine Push vom Server möglich

• Der Kommunikationsaufbau muss immer vom Client erfolgen, da die Firewalls einen initialen Verbindungsaufbau vom Server zu einem Cleint unterbinden müssen.

• bidirektional (full-duplex), stateful, persistent

• one to one

• internet tauglich

• sicher mittels TLS

• plattformunabhängig; Java, JavaScript, C++, ...

kein one-to-many Broadcast an mehrere Clients

• Ein one-to-many Verhalten muss im Server ausprogrammiert werden, d.h. es braucht ein Management der offenen WebSocket-Verbindungen.

HTTP:

• Punkt-zu-Punkt Verbindung (one-to-one)

• Request-Response Modell => Unidirektional => Client/Server

• Schwergewichtig

WebSocket

• Punkt-zu-Punkt Verbindung (one-to-one)

• Bidirektional => gleichwertige Kommunikationspartner

• Kein Applikationsprotokoll spezifiziert

=> soll leichtgewichtiges Protokoll sein

=> soll One-to-Many Verbindungen unterstützen

=> soll geringen Kommunikations-Overhead aufweisen

Keine Lösung

MQTT implementiert das Publish/Subscribe-Pattern.

• Der Paradigmenwechsel von einer Request/Response-zu einer ereignisgesteuerten Publish/Subscribe-Architektur ist hierbei der zentrale Aspekt. Sie ersetzt die Punkt-zu-Punkt-Verbindungen durch einen zentralen Server (Broker), zu dem sich Datenproduzenten (Publisher) und Datennutzer (Subscriber) gleiche rmassen verbinden können.
• Das Senden (publish) und Empfangen (subscribe) von Nachrichten funktioniert über sogenannte Topics

• MQTT ist ein asynchrones Protokoll.

• MQTT's Eigenschaften sind:

  • ist für unzuverlässige Netze mit geringer Bandbreite und hoher Latenz zeit entwickelt

  • ist robust bei Datenverlusten und schlechten Verbindungen

  • hat geringen Kommunikationsoverhead

  • kann mit TLS verschlüsselt werden

• sind eine Form von Adressen

• jede Nachricht ist einem Topic zugeordnet

• ist von der Funktions- und Schreibsyntax Ordnern in einem Filesystem sehr ähnlich

  • Beispiel: “5OG/Zimmer5/Temperatursensor/Temperatur”

• ist der “Endnutzer” der Kommunikation

• kann Nachrichten eines Topics empfangen (Subscriber)

• kann Nachrichten im (gleichen) Topic veröffentlichen (Publisher)

• ist das Backend für MQTT

• verwaltet und administriert jeglichen Datenverkehr:

  • Speicherung, Verwaltung und Verteilung aller Informationen zu Topics und deren Subscribers

Der MQTT-Broker ist:

• eine Software, die auf einem Computer (vor Ort oder in der Cloud) läuft.

• selbst installiert oder von einem Drittanbieter gehostet.

• sowohl in Open-Source-als auch in proprietären Implementierungen verfügbar.

• Zentrale Komponente

• Kommunikationsschaltstelle

• Unterschiedliche Implementationen verfügbar wie:

  • Referenz Implementation Eclipse Mosquitto => https://mosquitto.org/

  • Open Source MQTT Broker  VerneMQ => https://vernemq.com/

  • Free, public MQTT Broker Flespi => flespi.io

• Für jede Programmiersprache verfügbar

• Kann gleichzeitig sein:

  • Publisher => Sender von MQTT Messages

  • Subscriber => Empfänger von MQTT Messages

Ein weiteres wichtiges Konzept sind die drei Servicequalitäten bei der Datenübertragung 0, 1 und 2.

MQTT basiert auf TCP/IP, deshalb ist eine grosse Zuverlässigkeit bei der Übertragung bereits gegeben.

• Bei mobilen Netzen mit vielen Übertragungsfehlern durch Verbindungsprobleme ist dies aber nicht ausreichend.

• Daher hat das MQTT Protokoll Mechanismen eingebaut, die das erfolgreiche Übertragen von Nachrichten garantieren: Die Zusicherung variiert von keiner Garantie (Level 0) über die, dass die Nachricht mindestens einmal ankommt (Level 1), bis hin zur Garantie, dass die Nachricht genau einmal ankommt (Level 2). (Der Unterschied zwischen Level 1 und 2 liegt darin, dass es bei Level 1 passieren kann, dass eine Nachricht öfter einen Client erreicht.)

Je nach Anwendungsfall sollte der passende Level gewählt werden, denn je höher der Level, desto höher ist die benötigte Bandbreite.

• MQTT "publish/subscribe" Architektur

• Ideal für Constrained Netzwerke

  • "low bandwidth, high latency, data limits, and fragile connections"

• Quality of Service (QoS)

  • "The higher the QoS, the lower the performance"

• MQTT Clients können bei einem Verbindungsunterbruch benachrichtigt werden

  • "Last will and testament"

• MQTT Clients sind einfach zu implementieren

Keine Lösung