Hello !
Trace:

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:communications_and_communicating_sut:high_level_communication [2018/09/30 15:44] – Agrisniken:iot-open:communications_and_communicating_sut:high_level_communication [2020/07/20 09:00] (current) – external edit 127.0.0.1
Line 1: Line 1:
-==== Host layer protocols ==== +=====  =====  
-The host layers protocols include session (SES), presentation (PRES) and application (APP) level, particularly APP (application) layer in the regular Internet communication is dominated by the HTTP protocol and XML-related derivatives like i.e. SoAP. Also, FTP protocol for file transfer is ubiquitous; it exists since the beginnings of the Internet. Most of them are somehow related to the text. They're referenced as "WEB" protocols. Although these protocols are frequently used by advanced and more powerful IoT devices, this is problematic to be implemented in the constrained IoT devices world. I.e. event simplest HTTP header occupies at least 24+8+8+31 bytes without any payload!\\ There is also a problem to cross firewall boundaries when communication between subnetworks of the IoT devices is expected to occur. +<box #5374d5></box> 
 +<box #5374d5></box> 
 +===== Host Layer Protocols ===== 
 +<box #5374d5></box> 
 +<box #5374d5></box> 
 + 
 +The host layers protocols include session (SES), presentation (PRES) and application (APP) level, particularly APP (application) layer in the regular Internet communication is dominated by the HTTP protocol and XML-related derivatives, e.g. SoAP. Also, FTP protocol for file transfer is ubiquitous; it exists since the beginnings of the Internet. Most of them are somehow related to the text. They're referenced as "WEB" protocols. Although these protocols are frequently used by advanced and more powerful IoT devices, this is problematic to be implemented in the constrained IoT devices world. Event simplest HTTP header occupies at least 24 + 8 + 8 + 31 bytes without any payload! There is also a problem to cross firewall boundaries when communication between subnetworks of the IoT devices is expected to occur. 
 Some IoT designed protocols are reviewed below. Some IoT designed protocols are reviewed below.
  
-=== MQTT === +==== MQTT ==== 
-MQTT protocol ((https://www.hivemq.com/mqtt/)) was invented especially for the constrained IoT devices and low bandwidth networks. It is located in APP layer 7 of the ISO/OSI stack, but in fact, it covers all layers 5-7. It is text-based protocol yet very compact end efficient. Protocol stack implementation requires about 10kB of RAM/flash only. \\  +MQTT protocol ((https://www.hivemq.com/mqtt/)) was invented especially for the constrained IoT devices and low bandwidth networks. It is located in APP layer 7 of the ISO/OSI stack, but in fact, it covers all layers 5–7. It is text-based protocol yet very compact end efficient. Protocol stack implementation requires about 10 kB of RAM/flash only.  
-MQTT uses TCP connection so requires open connection channel (this is in opposite to UDP connections, where communications work in a way: "send and forget"). It is considered a drawback of the original MQTT protocol, but there do exist MQTT variations for non-TCP networks, i.e. MQTT-SN. Protocol definition provides reliability and delivery ensure mechanisms.\\+  
 +MQTT uses TCP connection so requires open connection channel (this is in opposite to UDP connections, where communications work in a way: "send and forget"). It is considered a drawback of the original MQTT protocol, but there do exist MQTT variations for non-TCP networks, e.g. MQTT-SN. Protocol definition provides reliability and delivery ensure mechanisms.\\
  
-The standard MQTT Message header is composed of just two bytes only (table {{ref>MQTT_header}})! There are 16 MQTT messages types. Some messages types require variable length header.+The standard MQTT Message header is composed of just two bytes only (Table {{ref>MQTT_header}})! There are 16 MQTT messages types. Some messages types require variable length header.
  
 <table MQTT_header> <table MQTT_header>
-<caption>MQTT standard message header</caption>+<caption>MQTT Standard Message Header</caption>
 ^bit  ^ 7 ^ 6 ^ 5 ^ 4 ^ 3 ^ 2 ^ 1 ^ 0 ^ ^bit  ^ 7 ^ 6 ^ 5 ^ 4 ^ 3 ^ 2 ^ 1 ^ 0 ^
 |byte 1  |  Message Type  ||||  DUP flag  |  Qos level  ||  RETAIN  | |byte 1  |  Message Type  ||||  DUP flag  |  Qos level  ||  RETAIN  |
Line 22: Line 29:
 <figure mqtt_broker> <figure mqtt_broker>
 {{ :en:iot-open:communications_and_communicating_sut:mqtt_broker.png?200 |}} {{ :en:iot-open:communications_and_communicating_sut:mqtt_broker.png?200 |}}
-<caption>MQTT Broker, Publishers and Subscribers</caption>+<caption>MQTT broker, publishers and subscribers.</caption>
 </figure> </figure>
  
-**MQTT Message**\\+===MQTT Message===
 MQTT is a text-based protocol and is data-agnostic. MQTT is a text-based protocol and is data-agnostic.
 A message is composed of a Topic (text) and a Payload (data).  A message is composed of a Topic (text) and a Payload (data). 
-The topic is a directory-like string with / "slash" delimiter. Thus all Topics constitute (or actually may represent) a kind of tree-like folders, similar to those on the file system.+The topic is a directory-like string with slash ("/") delimiter. Thus all Topics constitute (or actually may represent) a kind of tree-like folders, similar to those on the file system.
 The subscriber can subscribe to specific, single Topic, or to a variety of Topics using wildcards, where: The subscriber can subscribe to specific, single Topic, or to a variety of Topics using wildcards, where:
-  * # stands for entire branch,+  * # stands for the entire branch,
   * + stands for the single level.   * + stands for the single level.
  
-__Example scenario__.\\+//Example Scenario// 
 Publishers deliver some air quality information data in separate MQTT messages and for various rooms at the department Inf of the Universities (SUT, RTU, ITMO) to the Broker: Publishers deliver some air quality information data in separate MQTT messages and for various rooms at the department Inf of the Universities (SUT, RTU, ITMO) to the Broker:
 ^ Topic (publishers): ^ ^ Topic (publishers): ^
Line 55: Line 63:
 | RTU/# | | RTU/# |
  
-The payload (data) of the message is text as well, so in case one need to send binary data, it is necessary to encode it (i.e. Base64).+The payload (data) of the message is text as well, so in case one need to send binary data, it is necessary to encode it (e.g. Base64).
  
-**MQTT Broker**\\ +===MQTT Broker=== 
-MQTT Broker is a server for both publishers and subscribers. The connection is initiated from client to the Broker, so assuming it is located outside of a firewall, it breaks firewall its boundaries. +MQTT Broker is a server for both publishers and subscribers. The connection is initiated from the client to the Broker, so assuming it is located outside of a firewall, it breaks firewall its boundaries. 
-The Broker provides QoS (Quality of Service), and it can retain message payload. There are three levels of MQTT Broker QoS (supplied in the message level):+The Broker provides QoS (Quality of Service), and it can retain message payload. There are three levels of MQTT Broker QoS (supplied in 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 delivery of the message at least once to every subscriber. The broker expects acknowledgement to be sent from the subscriber. Otherwise, it retransmits data.   * Acknowledged service: Ensures delivery of the message at least once to every subscriber. The broker expects acknowledgement to be sent from the subscriber. Otherwise, it retransmits data.
Line 68: Line 76:
  
 MQTT offers some limited set of features (options): MQTT offers some limited set of features (options):
-  * Clean session flag for durable connections: +  * clean session flag for durable connections: 
-    * If set True, Broker removes all of the client subscriptions on client disconnect. +    * if set //TRUE//, Broker removes all of the client subscriptions on client disconnect; 
-    * Otherwise Broker collects messages (QoS depending) and delivers them on client reconnecting; thus connections remain idle. +    * otherwise Broker collects messages (QoS depending) and delivers them on client reconnecting; thus, connections remain idle; 
-  * MQTT "will": on connection lost, Broker will automatically "simulate" publishing of the pre-defined MQTT message (topic and payload). All clients subscribing this message (whether directly or via a wildcard) will be notified immediately. It is a great feature for failure/disaster discovery. +  * MQTT "will": on connection lost, Broker will automatically "simulate" publishing of the pre-defined MQTT message (topic and payload). All clients subscribing this message (whether directly or via a wildcard) will be notified immediately. It is a great feature for failure/disaster discovery; 
-  * Message retaining: it is a feature for regular messages. Any message can be set as retaining and in such case Broker will keep the last one. Once a new client subscribes topic, it will receive a retained message immediately even if the publisher is not publishing any message at the moment. This feature is **last known good value**. It is good to present publishers state (i.e. publisher sends retained message meaning "I'm going offline" and the disconnects. Any client connecting will be notified immediately about the device (client) state.\\+  * message retaining: it is a feature for regular messages. Any message can be set as retaining and in such case Broker will keep the last one. Once a new client subscribes topic, it will receive a retained message immediately even if the publisher is not publishing any message at the moment. This feature is **last known good value**. It is good to present publishers state (e.g. publisher sends retained message meaning "I'm going offline" and then disconnects. Any client connecting will be notified immediately about the device (client) state.\\
  
 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).
Line 78: Line 86:
 MQTT security is rather weak. MQTT Broker can offer user and password verification yet it is sent plain text. However, all communication between client and Broker may be encapsulated in SSL, encrypted stream.  MQTT security is rather weak. MQTT Broker can offer user and password verification yet it is sent plain text. However, all communication between client and Broker may be encapsulated in SSL, encrypted stream. 
  
-A short comparison of MQTT and HTTP protocols are presented in the table {{ref>http_vs_mqtt}}:+A short comparison of MQTT and HTTP protocols are presented in the Table {{ref>http_vs_mqtt}}.
 <table http_vs_mqtt> <table http_vs_mqtt>
 <caption>MQTT vs HTTP</caption> <caption>MQTT vs HTTP</caption>
 |  ^  MQTT  ^  HTTP  ^ |  ^  MQTT  ^  HTTP  ^
 ^ Design  | Data centric  | Document centric  | ^ Design  | Data centric  | Document centric  |
-^ Pattern  | Publish/Subscribe  | Request/Response  |+^ Pattern  | Publish/Subscribe  | Request/response  |
 ^ Complexity  | Simple  | Complex  | ^ Complexity  | Simple  | Complex  |
 ^ Message size  | Small, with 2 byte binary header  | Larger with text based status  | ^ Message size  | Small, with 2 byte binary header  | Larger with text based status  |
-^ Service levels  | 3 QoS  | none  | +^ Service levels  | 3 QoS  | None  | 
-^ Implementation  | C/C++: 10-30kB\\ Java ~100kB  | Depends on application but hits >MB  |+^ Implementation  | C/C++: 10–30 kB\\ Java ~100 kB  | Depends on application but hits > MB  |
 ^ Data distribution models  | 1-to-1\\ 1-to-N  | 1-to-1  | ^ Data distribution models  | 1-to-1\\ 1-to-N  | 1-to-1  |
 </table> </table>
  
-=== CoAP ===+==== CoAP ====
  
-CoAP protocol (RFC7252) originates from the REST (Representational State Transfer). CoAP does not use a centralised server as MQTT does, but every single device "hosts" a server on its own to provide available resources to the clients asking for service offering distributed resources. CoAP uses UDP (comparing to MQTT that uses TCP) and is stateless thus does not require memory for tracking the state. The CoAP implementation assumes every single IoT device has a unique ID and things can have multiple various representations. It is intended to link "things" together using existing standard methods. It is rather a resource-oriented (not document-oriented like HTTP/HTML), designed for slow IoT networks with a high degree of packet loss, also support devices to be periodically offline. CoAP uses URIs : +CoAP protocol (RFC7252) originates from the REST (Representational State Transfer). CoAP does not use a centralised server as MQTT does, but every single device "hosts" a server on its own to provide available resources to the clients asking for service offering distributed resources. CoAP uses UDP (comparing to MQTT that uses TCP) and is stateless thus does not require memory for tracking the state. The CoAP implementation assumes every single IoT device has a unique ID, and things can have multiple various representations. It is intended to link "things" together using existing standard methods. It is rather a resource-oriented (not document-oriented like HTTP/HTML), designed for slow IoT networks with a high degree of packet loss, also support devices to be periodically offline. CoAP uses URIs : 
-  * %%"coap:" "//" host[":"port] path ["?" query] to access a service / resource,%%+  * %%"coap:" "//" host[":"port] path ["?" query] to access a service/resource,%%
   * a secure, encrypted version uses "coaps" instead of "coap".   * a secure, encrypted version uses "coaps" instead of "coap".
 It supports various content types, can work with proxy and can be cached.\\ It supports various content types, can work with proxy and can be cached.\\
-The protocol is designed to be compact and simple to implement. The stack implementation takes only about 10kB or RAM and 100kB of storage. The header is only 4 bytes.\\+The protocol is designed to be compact and simple to implement. The stack implementation takes only about 10 kB of RAM and 100 kB of storage. The header is only 4 bytes. 
 CoAP protocol has a binary header to decrease overhead but payload depends on the content type. Initial, non-exclusive list of the payload types include: CoAP protocol has a binary header to decrease overhead but payload depends on the content type. Initial, non-exclusive list of the payload types include:
   * text/plain (charset=utf-8) (ID=0, RFC2046, RFC3676, RFC5147),   * text/plain (charset=utf-8) (ID=0, RFC2046, RFC3676, RFC5147),
Line 105: Line 114:
   * application/json (ID=50, RFC7159).   * application/json (ID=50, RFC7159).
  
-CoAP endpoint services are identified by unique IP and port number. However, they operate on the UDP instead of TCP (like, i.e. HTML does). The transfer in CoAP is made using non-reliable UDP network so that a message can appear duplicated, disappear or it can be delivered in other order than initially sent. Because of the nature of datagram communication, messages are exchanged asynchronously between two endpoints, transporting Requests and Responses.+CoAP endpoint services are identified by unique IP and port number. However, they operate on the UDP instead of TCP (like, e.g. HTML does). The transfer in CoAP is made using non-reliable UDP network so that a message can appear duplicated, disappear or it can be delivered in other order than initially sent. Because of the nature of datagram communication, messages are exchanged asynchronously between two endpoints, transporting Requests and Responses.
 CoAP messages can  be (non-exhaustive list):  CoAP messages can  be (non-exhaustive list): 
   * CON (Confirmable, those requiring ACK Acknowledge),    * CON (Confirmable, those requiring ACK Acknowledge), 
   * NON (Non-Confirmable, those that do not need ACK),    * NON (Non-Confirmable, those that do not need ACK), 
   * ACK (an acknowledgement message),    * ACK (an acknowledgement message), 
-  * RESET (sent if CON or NON was received, but the receiver cannot understand the context, i.e. part of the communication is missing because of device restart, messages memory loss, etc.). Empty RESET messages can be used to "ping" the device. +  * RESET (sent if CON or NON was received, but the receiver cannot understand the context, e.g. part of the communication is missing because of device restart, messages memory loss, etc.). Empty RESET messages can be used to "ping" the device. 
  
 Because of the UDP network characteristics, CoAP provides an efficient yet straightforward reliability mechanism to ensure successful delivery of messages: Because of the UDP network characteristics, CoAP provides an efficient yet straightforward reliability mechanism to ensure successful delivery of messages:
Line 117: Line 126:
 Request-reponse pair is identified by a unique "Token". Request-reponse pair is identified by a unique "Token".
 Sample request-response scenarios are presented in images below. Sample request-response scenarios are presented in images below.
-Sample CoAP message exchange scenarios between client and server are presented on images (two per image) {{ref>CoAP1}} and {{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 |}} {{ :en:iot-open:communications_and_communicating_sut:grafika8.png?400 |}}
-<caption>CoAP scenario 1: confirmable with time delay payload answer (0x70) and immediate payload answer (0x71)</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 |}} {{ :en:iot-open:communications_and_communicating_sut:grafika7.png?400 |}}
-<caption>CoAP scenario 2 - urecognized request (0x72) and non-confirmable request (0x73)</caption>+<caption>CoAP scenario 2: urecognized request (0 × 72) and non-confirmable request (0 × 73).</caption>
 </figure> </figure>
-The scenario on the image {{ref>CoAP1}} (left, with token 0x70) is executed in situation when a CoAP server device (a node) need some time to prepare data and cannot deliver information right away.  +The scenario in the Figure {{ref>CoAP1}} (left, with token 0 × 70) is executed in situation when a CoAP server device (a node) need some time to prepare data and cannot deliver information right away.  
-The scenario on the image {{ref>CoAP1}} (right, with token 0x71) is used, when a CoAP server can provide information to the client immediately.  +The scenario in Figure {{ref>CoAP1}} (right, with token 0 × 71) is used, when a CoAP server can provide information to the client immediately.  
-The scenario on the image {{ref>CoAP2}} (left, with token 0x72) appears, when a CoAP server cannot understand the request.  +The scenario in Figure {{ref>CoAP2}} (left, with token 0 × 72) appears when a CoAP server cannot understand the request.  
-The scenario on the image {{ref>CoAP2}} (right, with token 0x73) presents the situation where the request to the CoAP server was made with a non-confirmable request. +The scenario in Figure {{ref>CoAP2}} (right, with token 0 × 73) presents the situation where the request to the CoAP server was made with a non-confirmable request.
en/iot-open/communications_and_communicating_sut/high_level_communication.1538322284.txt.gz · Last modified: 2020/07/20 09:00 (external edit)
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