MQTT

MQTT is a lightweight publish/subscribe application protocol designed for machine-to-machine communication. The normal protocol runs over TCP; MQTT-SN is a UDP-oriented variant. Clients do not communicate directly: a central broker receives publications and forwards them to matching subscribers. This is a logical star even when the underlying network is a mesh.

Topics and filters

Topics are hierarchical strings such as bath/tub/temp.

• + matches exactly one level: bath/+/temp matches bath/tub/temp, not bath/floor/left/temp.
• # matches zero or more trailing levels: bath/# matches bath/temp and bath/radiator/towels/temp.
• Wildcards are for subscription filters, not publish topic names. A client must publish to a concrete topic such as iot/temp, not $share/exam/iot/temp and not home/+/temp.

Key features

• Retain flag: the broker stores the latest retained PUBLISH for a topic and sends it to a new matching subscriber. Useful for current device state or the last valid measurement. It is one retained value per topic and does not mean an unlimited history.
• Last Will and Testament: a client registers a will at connection time; the broker publishes it if the client disappears unexpectedly. A graceful disconnect does not trigger it. It can be retained.
• Topic alias (MQTT 5): the publisher first associates a short integer with a long topic string. On later messages the string can be omitted. The broker must store the alias mapping for that client connection so it can resolve the alias and route the message; the mapping is not a universal topic definition.
• Shared subscriptions (MQTT 5): use $share/<group>/<topic-filter>. Subscribers with the same group share the workload; the broker delivers each matching publication to one group member rather than broadcasting it to all of them. The publisher uses the ordinary topic, e.g. iot/temp.
• Sessions: MQTT 5 separates clean start from session expiry. The broker can retain subscriptions and queued messages for the configured expiry. Message expiry separately limits how long a queued PUBLISH remains valid.
• Request/response: MQTT 5 uses response-topic and optional correlation-data properties; it does not require a new message type.

QoS

QoS	Meaning	Typical use
0	At most once; best effort, may be lost.	Frequent ambient readings.
1	At least once; acknowledged, duplicates possible.	Retry-safe commands.
2	Exactly once delivery protocol.	Non-idempotent billing/critical operations.

For one publication, the publisher-to-broker QoS is the publication QoS. The broker-to-subscriber delivery is limited by the subscription QoS:

outgoing QoS = min(publication QoS, subscription QoS)

Therefore, a QoS-2 publication to a QoS-0 subscription is QoS 2 from publisher to broker and QoS 0 from broker to subscriber.

Exam patterns

• To receive basement/temperature, groundfloor/kitchen/temperature, and secondfloor/bathroom/temperature, subscribe to # (or another filter that actually matches all three depths). +/+/temperature misses the two-level first topic.
• To receive bathroom/ceiling/temp, bathroom/floor/temp, and bathroom/boiler/outlet/temp, use bathroom/+/temp only if the intended topic structure has exactly one variable level; the third example has two levels and therefore needs a matching filter such as bathroom/# plus application filtering, or consistent topic naming. This is a useful depth-check in exam answers.
• A subscription to home does not match home/groundfloor/temp; a wildcard is required.
• A publication to home/+/temp is invalid because wildcards cannot occur in a topic name.

Sources

• master-cs/raw/iot/3.4-IoT_Internetworking-MQTT.md
• master-cs/raw/iot/Question Sheet Week 4.md
• master-cs/raw/iot/Question Sheet Week 5.md