networks//network protocols//MQTT//MQTT QoS

MQTT QoS (quality of service) is the per-message delivery guarantee an MQTT client requests, one of three levels that trade bandwidth and latency for certainty, and it is used to decide whether a lost or repeated message matters for a given stream of telemetry or commands. Each level is a different handshake between the sender and the broker, and again between the broker and each subscriber.

MQTT QoS (quality of service) is the per-message delivery guarantee an MQTT client requests, one of three levels that trade bandwidth and latency for certainty, and it is used to decide whether a lost or repeated message matters for a given stream of telemetry or commands. Each level is a different handshake between the sender and the broker, and again between the broker and each subscriber.

QoS 0, at most once: the message is sent and forgotten. If the link drops, it is lost. Right for a temperature published every second, where the next reading replaces the lost one.

QoS 1, at least once: the sender keeps the message until it receives an acknowledgement (PUBACK) and resends if none arrives. Nothing is lost, but when the acknowledgement is the thing that got lost, the receiver gets the message twice.

QoS 2, exactly once: a four-step exchange (PUBLISH, PUBREC, PUBREL, PUBCOMP) ensures the message is handed over once between those two parties. It costs two round trips per message and state on both sides.

commands lost0 of 8 delivered twice2 valve50 % (meant 40 %) QoS 1 with 20 % of packets lost: 0 of 8 commands lost, 2 delivered twice, 23 packets sent. With relative commands (open 5 % more) the valve ends at 50 % instead of 40 %.

QoS 2 guarantees a message crosses one link once; it does not guarantee that the action behind it happens once.

A gateway that crashes after acting on a command and before recording that it did will act again on restart, whatever the QoS. Commands that move physical things are made safe by being idempotent (set the valve to 40 %, never open the valve 5 % more) and by carrying an identifier the receiver checks (idempotence).

The guarantee is hop by hop. A publisher at QoS 2 and a subscriber that subscribed at QoS 0 get QoS 0 on the second leg: the broker delivers at the lower of the two levels.

In a plant, most telemetry runs at QoS 0 or 1: a duplicated vibration summary is harmless and cheap to drop by timestamp, while QoS 2 doubles the round trips on a cellular link for little gain. QoS 1 plus idempotent consumers is the usual design.

QoS says nothing about time. A message queued during an outage and delivered at QoS 1 an hour later is delivered correctly and is stale; its payload should carry its event time so the subscriber can judge its age (fault semantics).

Against DDS, the robotics middleware: DDS also speaks of QoS, but its policies cover reliability, deadlines, history depth and durability per topic, a richer contract aimed at real-time data between robot processes. The same three letters, different promises.

Retained messages and the last will are separate features often confused with QoS: a retained message gives a new subscriber the last known value at once, and the last will tells everyone that a client vanished.