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
