This series is a short amalgamation of research that outlines the advantages of using MQTT as the communication protocol for low-bandwidth, low-power, IoT projects.
Background
MQTT (Message Queueing Telemetry Transport) is a binary based, asynchronous, protocol designed for low bandwidth M2M communication. Widely implemented and promoted by leading IoT platforms, such as AWS IoT and IBM Cloud, it aims to provide a light-weight means of sending data, particularly in areas with an unreliable internet connection, due to its compact packet size.
Architectural Features
Servers (Brokers)
Servers (originally brokers) are available as FOSS on either Windows or Linux; or, a cloud based service can be used such as Azure or IBM Cloud. They act as a proxy delivering messages to connected clients.
Topics
Each client connected to the server can subscribe or publish to a topic. A topic is a string that the server uses to filter messages for each client. Topics are hierarchical, with each level split by a forward slash, e.g:
`device/measurements/temperature/`
A key point to note is topics do not require initialisation before a client publishes or subscribes to it.
Topics support wildcard subscription using either + or # for single-level and multi-level respectively.
Client’s access to publish to a topic can be restricted by including the client ID within the topic descriptor, e.g given an ID of 1ef291b4-a739-48e8-a69b-54818b955e1d:
1ef291b4-a739-48e8-a69b-54818b955e1d/measurements/temperature
Quality of Service (QoS)
MQTT offers a varying level of message delivery assurance in its QoS. The QoS level is set on a per message basis and determines how the client and server communicate to deliver the message.
- 0 (At most once) — Message loss is acceptable at this level
- 1 (At least once) — Messages will arrive but duplication may occur
- 2 (Exactly once) — Messages will arrive once and once only
Last Will and Testament (LWT)
On the death of a connection the server can send a predetermined message to a given topic as defined by the client. The server maintains a keep alive timer for each client and can detect when a PINGREQ keep alive has not been received within the defined interval. Once this timer expires the LWT is immediately published.
This feature can be useful to detect when IoT devices go offline and can feed in to a monitoring API to automatically send notifications.
Oldest comments (0)