Differences
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:58] – 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 64: | Line 64: | ||
| The Broker provides QoS (Quality of Service) and can retain message payload. MQTT Broker QoS (supplied at the message level) has three levels. | The Broker provides QoS (Quality of Service) and can retain message payload. MQTT Broker QoS (supplied at the message level) has three levels. | ||
| * 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 | + | * Acknowledged service: Ensures message delivery to every subscriber |
| * Assured service: This two-step message delivery ensures the transmission is delivered exactly once to every subscriber. | * Assured service: This two-step message delivery ensures the transmission is delivered exactly once to every subscriber. | ||
| 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.\\ | ||
| Line 75: | Line 75: | ||
| * otherwise, the Broker collects messages (QoS depending) and delivers them on client reconnecting; | * otherwise, the Broker collects messages (QoS depending) and delivers them on client reconnecting; | ||
| * MQTT " | * MQTT " | ||
| - | * message retaining: it is a feature for regular messages. Any message can be set as retaining; in such case, the Broker will keep the last one. Once a new client subscribes to a topic will receive a retained message immediately, | + | * message retaining: it is a feature for regular messages. Any message can be set as retaining; in such case, the Broker will keep the last one. Once a new client subscribes to a topic, they will receive a retained message immediately, |
| Interestingly, | Interestingly, | ||
| 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" | ||
