This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
en:iot-open:networking2:applicationnetworkprotocols [2024/05/27 10:56] – pczekalski | en:iot-open:networking2:applicationnetworkprotocols [2024/08/28 15:56] (current) – pczekalski | ||
---|---|---|---|
Line 23: | Line 23: | ||
MQTT requires a centralised MQTT Broker located outside firewalls and NATs, where all clients connect, send and receive messages via the **publish/ | MQTT requires a centralised MQTT Broker located outside firewalls and NATs, where all clients connect, send and receive messages via the **publish/ | ||
<figure mqtt_broker> | <figure mqtt_broker> | ||
- | {{ : | + | {{ : |
< | < | ||
</ | </ | ||
Line 62: | Line 62: | ||
**MQTT Broker**\\ | **MQTT Broker**\\ | ||
MQTT Broker is a server for both publishers and subscribers. The connection is initiated from the client to the Broker, so assuming the Broker is located outside a firewall, it breaks its boundaries.\\ | MQTT Broker is a server for both publishers and subscribers. The connection is initiated from the client to the Broker, so assuming the Broker is located outside a firewall, it breaks its boundaries.\\ | ||
- | The Broker provides QoS (Quality of Service) and can retain message payload. | + | The Broker provides QoS (Quality of Service) and can retain message payload. MQTT Broker QoS (supplied at the message level) |
* Unacknowledged service: Ensures that MQTT message is delivered at most once to each subscriber. | * Unacknowledged service: Ensures that MQTT message is delivered at most once to each subscriber. | ||
- | * Acknowledged service: Ensures message delivery at least once to every subscriber. The Broker expects acknowledgement to be sent from the subscriber. Otherwise, it retransmits data. | + | * Acknowledged service: Ensures message delivery |
- | * Assured service: This is a two-step delivery | + | * Assured service: This two-step |
Providing unique packet IDs in the MQTT frame is vital for Acknowledged and Assured services.\\ | Providing unique packet IDs in the MQTT frame is vital for Acknowledged and Assured services.\\ | ||
- | The DUP flag (byte 1, bit 3) represents information sent by the publisher | + | The DUP flag (byte 1, bit 3) represents information sent by the publisher, indicating whether |
MQTT offers a limited set of features (options): | MQTT offers a limited set of features (options): | ||
Line 79: | Line 79: | ||
Interestingly, | Interestingly, | ||
- | MQTT security is relatively weak. MQTT Broker can offer user and password verification sent in plain text. However, all communication between client and Broker may be encapsulated in SSL, encrypted stream. | + | MQTT security is relatively weak. The MQTT Broker can offer user and password verification sent in plain text. However, all communication between |
A short comparison of MQTT and HTTP protocols is presented in table {{ref> | A short comparison of MQTT and HTTP protocols is presented in table {{ref> | ||
Line 125: | Line 125: | ||
Sample CoAP message exchange scenarios between client and server are presented (two per image) in figure {{ref> | Sample CoAP message exchange scenarios between client and server are presented (two per image) in figure {{ref> | ||
<figure CoAP1> | <figure CoAP1> | ||
- | {{ : | + | {{ : |
< | < | ||
</ | </ | ||
<figure CoAP2> | <figure CoAP2> | ||
- | {{ : | + | {{ : |
< | < | ||
</ | </ | ||
Line 143: | Line 143: | ||
< | < | ||
</ | </ | ||
- | <todo @pczekalski> | ||
AMQP uses TCP/IP. AMQP is intended to work in non-reliable networks; thus, the protocol has a message acknowledgement mechanism to ensure delivery. A message is removed from the queue only if it has been acknowledged. Besides acknowledged delivery, it is also possible to use an unacknowledged one that does not involve acknowledgements. If a message cannot be routed (for any reason), it can be returned to the publisher, dropped or placed in the "dead letter queue" | AMQP uses TCP/IP. AMQP is intended to work in non-reliable networks; thus, the protocol has a message acknowledgement mechanism to ensure delivery. A message is removed from the queue only if it has been acknowledged. Besides acknowledged delivery, it is also possible to use an unacknowledged one that does not involve acknowledgements. If a message cannot be routed (for any reason), it can be returned to the publisher, dropped or placed in the "dead letter queue" | ||