Week 4 - Lecture 7 - Application Layer Protocols Flashcards
List some protocols for the IoT stack application layer
Message Queue Telemetry Transport (MQTT)
Constrained Application Protocol (CoAP)
Extensible Messaging and Presence Protocol (XMPP)
Advanced Message Queueing Protocol (AMQP)
Data Distribution Service (DDS) Protocol
Representational State Transfer Hypertext Transfer Protocol (REST HTTP)
What are some interaction models and examples
Request/response -> client/server
- REST HTTP
CoAP, DDS
Publish/subscribe -> publisher-subscriber
MQTT AMQP XMPP
Many protocols continually evolve and may support (to an extent) both models
Handshaking and data transfer
Exclusive to Websocket only
Describe REST HTTP
Use on the web
HTTP/1.1 is the most widely used
RESTful HTTP allows devices to exchange information through CRUD
TCP used at the transport layer
HTTP doesn’t explicitly define any QoS levels
https uses the TLS protocol
Version 2 new features reduce message size, enable server push, not in strict order exchanges of several messages over a single connection
JSON typically used to represent the data
In HTTP1.0 the TCP connection is closed after a single HTTP request/reply pair
In HTTP 1.1 a keep-alive-mechanism was introduce, where a TCP connection could be reused for sending multiple requests to the server without waiting for a response (pipelining). Once the requests are all sent, the browser starts listening for responses and HTTP 1.1 specification requires that a server must send its responses to those requests in the same order that the requests were received
Enables a REST model for different devices when HTTP is combined with REST
What is CRUD?
Create Read Update Delete
PUSH GET PUT DELETE
HTTP Pros and Cons
Enables REST architecture
TCP guarantees reliable communication
Appropriate for large data transfer, latency insensitive
Use to TCP and TLS lead to high overheads
- not appropriate for constrained devices
Does not support server push notifications
- A client should place a request
Size of header and message payloads depend on the web server or the programming technology
JSON usage not optimised for resource constrained environments
REST is commendable because devices can make their state information easily available
Constrained Application Protocol (CoAP)
Supports both request/response and resource/observe
Interoperable with HTTP
- Uses universal resource Identifier (URI) instead of topics
Lightweight protocol binary encoded
- Headers, methods and status codes
Uses UDP instead of TCP
Fixed headers of 4 bytes with small message payloads up to maximum size dependet on the web server or the programming technology
- Messages in binary format
Quality of Service (QoS) is enabled through confirmable (CON) or non-confirmable (NON)
When a client sends one or multiple CoAP requests to the server and gets the response, this response is not sent over a previously established connection, but exchanged asynchronously over CoAP messages, which effectively reduces reliability
Two logically different layers. One of these layers follows the request/response model, implementing the RESTful paradigm and enables CoAP clients to behave similar to HTTP when sending requests
Second layer addresses the reliability issue as a result of the use of the User Datagram Protocol (UDP) at the transport layer
What benefits might HTTP 2.0 have?
More efficient use of network resources and shorter total latency by using compressed headers and by exchanging multiple parallel messages over the same connection. Furthermore, it introduces the server push mode, in which the server can forward data to clients without waiting for requests. These features seem to be useful in IoT applications and remain to be realised and tested for their performance
What are the four types of messages used in CoAP message layer?
CON (Confirmable)
NON (non-confirmable)
ACK (Acknowledgement)
RST (reset)
CON requires feedback from the receiver of ACK
The resource/observe model uses the option “observe” in the GET method. In this case the server puts the client in the list of observers of the specified quantity and the client receives updates when this quantity changes. In this way communication is particularly close to the publish/subscribe logic.
MQTT
Mosquito (MQTT) was introduced in 1999 and is one of the oldest M2M (machine to machine) communication protocols
Utilises the publish/subscribe model
Utilises the transmission control protocol at the transport layer and TLS/SSL for security
Also a binary protocol
Headers of (at least) 2-bytes with small message payloads up to maximum size of 256MB
MQTT
Mosquito (MQTT) was introduced in 1999 and is one of the oldest M2M (machine to machine) communication protocols
Utilises the publish/subscribe model
Utilises the transmission control protocol at the transport layer and TLS/SSL for security
Also a binary protocol
Headers of (at least) 2-bytes with small message payloads up to maximum size of 256MB (If you want to send a message > 256mb it’s likely that there is a problem with the protocol design
What is DUP in MQTT?
Duplicate
MQTT QoS
Quality of service
QoS 0 (at most once)
QoS 1 (at least once)
Confirmation message necessary, publisher resends within. a defined period of time
QoS 2 (exactly once)
Guarantees the message will be delivered exactly once without duplications
- Slow, so less appropriate for IoT
Level can be defined in the publish and subscribe message
What is the retain flag for?
Stores messages for future subscribers
Advanced Message Queuing Protocol (AMQP)
AMQP is a lightweight M2M protocol
It’s a binary protocol
- Fixed headers of 8 bytes with small message payloads up to maximum size dependent on the broker/server or the programming technology
AMQP uses TCP as a default transport protocol and TLS/SSL and SASL for security
Reliability is a core feature
Offers two QoS levels:
- Unsettle format (not reliable)
- Settle Format (reliable)
High power, processing and memory requirements making it a heavy protocol. Better suited in parts of the system that are not bandwidth and latency restricted, with more processing power.
Not recommended for systems with batter power
AMQP 0.9.1 and AMQP 1.0 have completely different messaging paradigms
0.9.1 is publish/subscribe model
Uses two entities in a broker:
- exchanges and message queues
Exchanges are the part of the broker used to route messages received from publishers to the appropriate queues.
Message queues are the queues on which messages are routed and remain there until they are read by the corresponding subscriber.
1.0 follows a peer-to-peer paradigm, can be used without a broker in the middle. broker only needed for a store and forward mechanism, in other cases direct messaging is possible.. Supporting different topologies increases the flexibility, client-to-client client-to-broker and broker-to-broker.
Offers many capabilities but is mainly confined to servers and strong autonomous nodes.
Websocket protocol
Does not follow the response/request or the publish/subscribe model
- Comprises a handshake and a data transfer process.
Utilises TCP at the transport layer
Enables two-way communication, saving the need for creating multiple connections
- WebSocket connections are fully asynchronous, unlike HTTP
Web socket can decrease the latency by a factor of three compared to HTTP
Handshake resembles that of HTTP.
After handshake, headers are removed for the rest of the session and the client exchanges messages with the server in an asynchronous two-way (dullduplex) communication with an overhead of only 2 bytes (when masking is not used). The session terminates either from the server side or from the client when it is no longer required. Provides a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections.
CLient and server can both send frames at any time without any restriction, closer to TCP than any of the HTTP protocols Only relation to HTTP is that its handshake is interpreted by HTTP servers as an Upgrade request. By default, the WebSocket Protocol uses port 80 for regular WebSocket connections
Order HTTP, MQTT, CoAP and AMQP in terms of message size and overhead
Smallest
CoAp
MQTT
AMQP
HTTP
Largest
In terms of both message size and overhead, this is partially because of TCP, CoAP runs on UDP that does not add connection overheads as UDP works in fire and forget basis. This situation decreases the overall overhead considerably, and thus the whole message size.
HTTP among all four is the most heavy and verbose.
MQTT is slightly above CoAP because of the use of TCP instead of UDP but they are still both very comparable, good for short messages with little data
Order HTTP, MQTT, CoAP and AMQP in terms of power consumption and resource requirement
Least
CoAp
MQTT
AMQP
HTTP
Most
CoAP and MQTT are designed for low bandwidth and resource-constrained devices and can be deployed on an 8-bit controller and 100’s of bytes of memory.
CoAP only consumes slightly less resources
Order HTTP, MQTT, CoAP and AMQP in terms of bandwidth and latency
Least
CoAp
MQTT
AMQP
HTTP
Most
Using TCP requires lots of latency and bandwidth usage
Order HTTP, MQTT, CoAP and AMQP in terms of interoperability
Least
MQTT
AMQP
CoAP
HTTP
Most
Interoperability iss the biggest issue among all IoT protocols. MQTT only supports publish/subscribe which barely covers all of the use cases within IoT.
In AMQP it is common to use serialization formats such as Protocol Buffers, Message Pack, Thrift and JSON to serialize structured data in order to publish it as the message payload.
CoAP is a part of the web architecture and best suited for devices that support UDP or a UDP analogue, however, making it limited to a few special kinds of IoT devices.
HTTP-based RESTful clients and servers are the most interoperable because all this is needed to support message exchanges, is an HTTP stack (either on the client or the server).
Order HTTP, MQTT, CoAP and AMQP in terms of reliability / QoS
Most
MQTT
AMQP
CoAP
HTTP
Least
AMQP specifies two QoS levels, CoAP doesn’t support explicit QoS, it facilitates the use of (NON) and (CON), which is similar to MQTT QoS 0 and 1
Order HTTP, MQTT, CoAP and AMQP in terms of usage and standardization
Most Usage, Least standardization
MQTT
AMQP
CoAP
HTTP
Least Usage, Most standardization
Which protocols are open source / Free?
HTTP is free
AMQP, MQTT and CoAP are open source
What are some evaluation metrics for network protocols?
Protocol efficiency
Round trip time (RTT)
What is protocol efficiency?
Ratio between the number of useful information bytes, i.e., application layer payload, and the total number of bytes exchanged at application and transport layers
