Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
en:iot-open:networking2:applicationnetworkprotocols [2024/05/27 10:56] pczekalskien: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/subscribe** model. The client can act as publisher and subscriber simultaneously. Figure {{ref>mqtt_broker}} presents a publish-subscribe model idea. MQTT requires a centralised MQTT Broker located outside firewalls and NATs, where all clients connect, send and receive messages via the **publish/subscribe** model. The client can act as publisher and subscriber simultaneously. Figure {{ref>mqtt_broker}} presents a publish-subscribe model idea.
 <figure mqtt_broker> <figure mqtt_broker>
-{{ :en:iot-open:communications_and_communicating_sut:mqtt_broker.png?200 | MQTT Broker, publishers and subscribers}}+{{ :en:iot-open:communications_and_communicating_sut:mqtt_broker.png?320 | MQTT Broker, publishers and subscribers}}
 <caption>MQTT Broker, Publishers and Subscribers</caption> <caption>MQTT Broker, Publishers and Subscribers</caption>
 </figure> </figure>
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. There are three levels of MQTT Broker QoS (supplied at the message level).+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 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 to every subscriber at least once. The Broker expects acknowledgement to be sent from the subscriber. Otherwise, it retransmits data. 
-  * Assured service: This is a two-step delivery of the message and 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.\\
  
-The DUP flag (byte 1, bit 3) represents information sent by the publisher if the message is a "first try" (0) or a retransmitted one (1). It is primarily for internal purposesand this flag is never propagated to the subscribers.+The DUP flag (byte 1, bit 3) represents information sent by the publisher, indicating whether the message is a "first try" (0) or a retransmitted one (1). This flag is primarily for internal purposes and is never propagated to the subscribers.
  
 MQTT offers a limited set of features (options): MQTT offers a limited set of features (options):
Line 79: Line 79:
 Interestingly, MQTT is a protocol used by Facebook Messenger ((https://www.facebook.com/notes/facebook-engineering/building-facebook-messenger/10150259350998920/)). It is also implemented natively in Microsoft Azure and Amazon Web Services (among many others). Interestingly, MQTT is a protocol used by Facebook Messenger ((https://www.facebook.com/notes/facebook-engineering/building-facebook-messenger/10150259350998920/)). It is also implemented natively in Microsoft Azure and Amazon Web Services (among many others).
  
-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 SSLencrypted stream. +MQTT security is relatively weak. The MQTT Broker can offer user and password verification sent in plain text. However, all communication between the client and Broker may be encapsulated in an SSL-encrypted stream. 
  
 A short comparison of MQTT and HTTP protocols is presented in table {{ref>http_vs_mqtt}}. A short comparison of MQTT and HTTP protocols is presented in table {{ref>http_vs_mqtt}}.
Line 125: Line 125:
 Sample CoAP message exchange scenarios between client and server are presented (two per image) in figure {{ref>CoAP1}} and figure {{ref>CoAP2}}. Sample CoAP message exchange scenarios between client and server are presented (two per image) in figure {{ref>CoAP1}} and figure {{ref>CoAP2}}.
 <figure CoAP1> <figure CoAP1>
-{{ :en:iot-open:communications_and_communicating_sut:grafika8.png?400 | CoAP scenario 1: confirmable with time delay payload answer (0 × 70) and immediate payload answer (0 × 71)}}+{{ :en:iot-open:communications_and_communicating_sut:grafika8.png?620 | CoAP scenario 1: confirmable with time delay payload answer (0 × 70) and immediate payload answer (0 × 71)}}
 <caption>CoAP scenario 1: confirmable with time delay payload answer (0 × 70) and immediate payload answer (0 × 71)</caption> <caption>CoAP scenario 1: confirmable with time delay payload answer (0 × 70) and immediate payload answer (0 × 71)</caption>
 </figure> </figure>
 <figure CoAP2> <figure CoAP2>
-{{ :en:iot-open:communications_and_communicating_sut:grafika7.png?400 | CoAP scenario 2: unrecognized request (0 × 72) and non-confirmable request (0 × 73)}}+{{ :en:iot-open:communications_and_communicating_sut:grafika7.png?620 | CoAP scenario 2: unrecognized request (0 × 72) and non-confirmable request (0 × 73)}}
 <caption>CoAP scenario 2: unrecognized request (0 × 72) and non-confirmable request (0 × 73)</caption> <caption>CoAP scenario 2: unrecognized request (0 × 72) and non-confirmable request (0 × 73)</caption>
 </figure> </figure>
Line 143: Line 143:
 <caption>AMQP protocol messages flow</caption> <caption>AMQP protocol messages flow</caption>
 </figure> </figure>
-<todo @pczekalski>AMQP higher resolutions</todo> 
 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". The behaviour is defined along with a message. Opposite to MQTT, in AMQP protocol, the connection status is unknown; thus, there is no mechanism to let other devices know that some node has disconnected, such as the last will in MQTT.  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". The behaviour is defined along with a message. Opposite to MQTT, in AMQP protocol, the connection status is unknown; thus, there is no mechanism to let other devices know that some node has disconnected, such as the last will in MQTT. 
  
en/iot-open/networking2/applicationnetworkprotocols.1716807368.txt.gz · Last modified: 2024/05/27 10:56 by pczekalski
CC Attribution-Share Alike 4.0 International
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0