webnt
WING FHNW
WING FHNW
Welche Aussagen zum WebSocket Applikationsprotokoll sind korrekt?
Problemdarstellung MQTT
Summary: HTTP Eigenschaften
unidirektional, synchron, stateless
one-to-one
internettauglich
sicher, mittels TLS
Plattformunabhängig
Aber kein Push vom Server möglich:
Der Kommunikationsaufbau muss immer vom Client erfolgen, da die Firewalls einen initialen Verbindungsaufbau vom Server zu einem Client unterbinden müssen.
Summary: WebSocket Eigenschaften
bidirektional (full-duplex)
one-to-one
internettauglich
sicher, mittles TLS
Plattformunabhängig (Java usw.)
Aber 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.
Motivation HTTP
- Punkt-zu-Punkt Verbindung (one-to-one)
- Request-Response Modell => Unidirektional => Client/Server
- Schwergewichtig
Motivation Websocket
- Punkt-zu-Punkt Verbindung (one-to-one)
- Bidirektional => gleichwertige Kommunikationspartner
- Kein Applikationsprotokoll spezifiziert
Motivation MQTT
- soll leichtgewichtiges Protokoll sein
- soll One-to-Many Verbindungen unterstützen
- soll geringen Kommunikations-Overhead aufweisen
Bedeutung MQTT
Message Queue Telemetry Transport
Funktion MQTT
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) gleichermassen verbinden können.
Wie funktioniert Senden und Empfangen beim MQTT?
Das Senden (publish) und Empfangen (subscribe) von Nachrichten funktioniert über sogenannte Topics.
Was für eine Art Protokoll ist das MQTT?
Ein Asynchrones
Eigenschaften MQTT
- ist für unzuverlässige Netze mit geringer Bandbreite und hoher Latenzzeit entwickelt
. ist robust bei Datenverlusten und schlechten Verbindungen
- hat geringen Kommunikationsoverhead
- kann mit TLS verschlüsselt werden
Was ist ein MQTT Topic
- 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”
Was ist ein MQTT Client
- ist der “Endnutzer” der Kommunikation
- kann Nachrichten eines Topics empfangen (Subscriber)
- kann Nachrichten im (gleichen) Topic veröffentlichen (Publisher)
Was ist ein MQTT Broker?
- ist das Backend für MQTT
- verwaltet und administriert jeglichen Datenverkehr:
Speicherung, Verwaltung und Verteilung aller Informationen zu Topics und deren Subscribers
Eigenschaften MQTT Broker
- 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.
MQTT Cloud Infrastruktur
MQTT Komponenten
MQTT Broker
-Zentrale Komponente
- Kommunikationsschaltstelle
- Unterschiedliche Implementationen verfügbar
MQTT Client
Für jede Programmiersprache verfügbar
Kann gleichzeitig sein:
Publisher à Sender von MQTT Messages
Subscriber à Empfänger von MQTT Messages
Wofür ist die Qualitätskontrolle MQTT QoS?
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.
Wichtigsten Features von MQTT
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
Die asynchrone, serielle Datenkommunikation braucht 2 Datenleitungen im Duplex-Modus.
"9600 8N1" bedeuten:
Welche Aussagen zur Länge des Datenpakets sind korrekt?
Bei Little-Endian wird das MSB zuerst versendet.
MSB = Most significant bit
Die Baudrate wird mit Bytes pro Sekunde (bps) angegeben.
Es sind Bits pro Sekunde
Welche Aussagen zum Paritybit sind korrekt?
Die serielle Datenkommunikation hat immer ein Stopbit.
Die serielle Datenkommunikation hat immer ein Startbit.
Die asynchrone, serielle Datenkommunikation braucht 2 Datenleitungen im Simplex-Modus.
Die synchrone, serielle Datenkommunikation braucht 2 Datenleitungen im Simplex-Modus.
Was bedeuted die bezeichnung?
Baudrate: 9600 bps
Data Bits: 8
Parity Bit: None
Stop Bit: 1
Litttle Endian: Start mit LSB
Was ist die minimale Voraussetzung für die Wahl der Baudrate?
Die beiden Geräte müssen dieselbe Baudrate besitzen. am gebräuchlichsten ist 9600bps
Was zeigt die Bits pro Sekunde an?
Die Baudrate
Welches sind die Bits welche für die Synchronisation zuständig sind?
Startbit (wechselt auf 0) und Stoppbit (Wechselt auf 1) --> Sie markieren Anfang und Ende
Asynchrones, serielles Protokoll: Regeln
Asynchrones, serielles Protokoll: Regeln
Kostengünstigste Protokollarten (absteigend)
1. Asynchron-Seriell
2. Synchron-Paralell
3. Parallel
Effizienz der Protokollarten (absteigend)
1. Parallel
2. Synchron-Seriell
3. Asynchron-Seriell
Die Daten b0-b7 bestehen aus den Werten 0 und 1.
Die Daten werden nacheinander von Out zu In übertragen.
Es wird keine externes Clock-Signal eingesetzt.
Es braucht 1 Leitung (1 Daten).
Asynchrone, Serielle Kommunikation
Die Daten b0-b7 bestehen aus den Werten 0 und 1.
Die Daten werden nacheinander von Out zu In übertragen. innerhalb eines Clock-Taktes (CLK).
Es braucht 2 Leitungen (1 Daten und 1 Clock).
Synchrone, Serielle Kommunikation
-
- 1 / 189
-
Cartes-fiches
Welche Aussagen zum WebSocket Protokoll sind korrekt?
WebSocket ist ein one-to-many Protokoll.
Mit WebSocket können mehrere Clients bedient werden.
Das Applikationsprotokoll ist bei WebSocket gegeben.
Der initiale Request kann auch mit dem Schema "http" gestartet werden.
Der initiale Request ist ein HTTP-Request
Der initiale Request ist eine HTTP-PUT Request.
GET
Der HTTP-Endpoint für den initialen Request ist spezifiziert
Welche Aussagen zum WebSocket Upgrade Request sind korrekt ?
Welche Aussagen zum WebSocket Applikationsprotokoll sind korrekt?
Problemdarstellung MQTT
Summary: HTTP Eigenschaften
unidirektional, synchron, stateless
one-to-one
internettauglich
sicher, mittels TLS
Plattformunabhängig
Aber kein Push vom Server möglich:
Der Kommunikationsaufbau muss immer vom Client erfolgen, da die Firewalls einen initialen Verbindungsaufbau vom Server zu einem Client unterbinden müssen.
Summary: WebSocket Eigenschaften
bidirektional (full-duplex)
one-to-one
internettauglich
sicher, mittles TLS
Plattformunabhängig (Java usw.)
Aber 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.
Motivation HTTP
- Punkt-zu-Punkt Verbindung (one-to-one)
- Request-Response Modell => Unidirektional => Client/Server
- Schwergewichtig
Motivation Websocket
- Punkt-zu-Punkt Verbindung (one-to-one)
- Bidirektional => gleichwertige Kommunikationspartner
- Kein Applikationsprotokoll spezifiziert
Motivation MQTT
- soll leichtgewichtiges Protokoll sein
- soll One-to-Many Verbindungen unterstützen
- soll geringen Kommunikations-Overhead aufweisen
Bedeutung MQTT
Message Queue Telemetry Transport
Funktion MQTT
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) gleichermassen verbinden können.
Wie funktioniert Senden und Empfangen beim MQTT?
Das Senden (publish) und Empfangen (subscribe) von Nachrichten funktioniert über sogenannte Topics.
Was für eine Art Protokoll ist das MQTT?
Ein Asynchrones
Eigenschaften MQTT
- ist für unzuverlässige Netze mit geringer Bandbreite und hoher Latenzzeit entwickelt
. ist robust bei Datenverlusten und schlechten Verbindungen
- hat geringen Kommunikationsoverhead
- kann mit TLS verschlüsselt werden
Was ist ein MQTT Topic
- 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”
Was ist ein MQTT Client
- ist der “Endnutzer” der Kommunikation
- kann Nachrichten eines Topics empfangen (Subscriber)
- kann Nachrichten im (gleichen) Topic veröffentlichen (Publisher)
Was ist ein MQTT Broker?
- ist das Backend für MQTT
- verwaltet und administriert jeglichen Datenverkehr:
Speicherung, Verwaltung und Verteilung aller Informationen zu Topics und deren Subscribers
Eigenschaften MQTT Broker
- 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.
MQTT Cloud Infrastruktur
MQTT Komponenten
MQTT Broker
-Zentrale Komponente
- Kommunikationsschaltstelle
- Unterschiedliche Implementationen verfügbar
MQTT Client
Für jede Programmiersprache verfügbar
Kann gleichzeitig sein:
Publisher à Sender von MQTT Messages
Subscriber à Empfänger von MQTT Messages
Wofür ist die Qualitätskontrolle MQTT QoS?
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.
Wichtigsten Features von MQTT
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
