MQTT protocol: topics, QoS, sessions and security

Publish and subscribe rather than direct requests

In a typical MQTT system, clients connect to a broker. A publisher sends a message to a named topic, and subscribers receive messages matching their filters. The publisher does not need the network address of every consumer. This allows an application to be added without redesigning the sensor, provided access permissions and the payload contract support the new use.

This differs from a simple HTTP request in which one client directly asks a server for a resource or submits information to an endpoint. Neither model is universally better. MQTT is useful for ongoing message exchange and distributing observations to several consumers. What is MQTT? gives a broader introduction, while the broker guide focuses on operating the central service.

Connections, client identities and keep alive

A client establishes a network connection and starts an MQTT session through a connection exchange. The broker can accept or refuse it. Client identifiers and authentication settings are important because they influence permissions and session behaviour. Do not confuse a logical device identifier inside a payload with the client identifier used by a gateway publishing on behalf of several devices.

Keep alive mechanisms help detect an unresponsive connection, but a connected client is not proof of fresh sensor data. A gateway might remain connected while its local instrument is unavailable. Monitor application receipt and source timestamps separately from transport health. This distinction is particularly important when reporting intervals are long or a gateway is forwarding previously buffered observations.

Topic names and subscription filters

Topic names are routing strings, and their structure is defined by the application. Slashes can organise levels such as a site, asset and measurement. Names are case sensitive. Keep the convention stable and document whether identifiers refer to physical devices, gateways or logical assets. Renaming topics casually can break subscribers even when every component still connects successfully.

Subscription filters may include a single level wildcard or a multiple level wildcard where the protocol permits them. Filters belong in subscriptions, not publication topic names. Authorisation should constrain both publishing and subscription patterns. Avoid unrestricted wildcard access when a customer or application should only see a subset of devices, and test permissions using representative allowed and forbidden operations.

Quality of service and duplicate handling

QoS 0 provides an unacknowledged delivery path. QoS 1 provides at least once delivery, which means the receiver must tolerate duplicates. QoS 2 introduces a longer exchange for exactly once delivery within the relevant MQTT interaction. A subscription can also limit the delivery level used on the broker to subscriber leg, so follow both parts of the message journey.

Do not translate a protocol acknowledgement into a claim of exactly once business processing. A consumer might acknowledge transport receipt before a database write fails. Conversely, it might save a reading and disconnect before completing an acknowledgement. Stable event identifiers, appropriate acknowledgement timing and idempotent storage remain necessary when application integrity matters.

Retained messages and state

A publisher can ask the broker to retain a message for a topic. Later matching subscribers can then receive a latest known value without waiting for the next publication. This is convenient for state, such as whether equipment was last reported running. However, retained data must include enough timing context for an application to judge whether it remains relevant.

Retained messages are not a complete event history. They do not replace a time series database or reconstruct every intermediate change. Define how to remove obsolete retained values when equipment is retired. If a dashboard treats any newly received retained payload as a current observation, it can show misleading information after a long period without real source updates.

Session behaviour and protocol versions

MQTT 3.1.1 and MQTT 5.0 differ in capabilities and configuration. MQTT 5 adds features including richer reason codes, message expiry and more explicit session controls. Choose a version supported by the actual clients and broker, and document the settings. A version number alone does not tell operators whether messages will be queued during an outage.

Persistent session behaviour depends on client identity, connection options and broker policies. Test disconnection, restart and recovery, including queue limits and expiry. If two independent clients use the same identity, they may disconnect one another. If identities change on every deployment, subscriptions and queued messages may not recover as the application designer expected.

Payload meaning belongs to the application

MQTT transports payloads without prescribing their business schema. JSON is common, but binary formats are also possible. Agree on field names, units, timestamps, event identity and schema version. Limit message size and reject malformed or unreasonable values before persistence. A successfully delivered payload can still be useless if consumers interpret the same number differently.

Our IoT sensors guide explains measurement context, while industrial IoT discusses controller and machine data. Preserve original timestamps and quality indicators where available. Do not silently convert missing readings to zero, and distinguish a delayed observation from a current one. These application choices determine whether the transported information remains trustworthy.

Security and practical verification

Use TLS with certificate validation where the network and deployment require protected transport. Configure authentication and least privilege topic permissions separately. MQTT does not turn a public plaintext listener into a secure service by itself. Keep passwords, tokens and private keys outside shared code, and plan credential rotation and device revocation.

Validate a complete workflow before expanding: connect, publish, subscribe, store and display. Then test forbidden topics, invalid payloads, network interruption and duplicate delivery. Review the connector catalogue when planning application integration, but verify the exact message contract. The MQTT protocol provides messaging tools; dependable telemetry comes from combining them with clear semantics, secure operations and tested recovery.