9 min read #networking #real-time-communication
On this page

MQTT

The most concise pub/sub protocol designed for low-bandwidth, high-latency, and unreliable IoT networks—QoS 0/1/2 provide three levels of delivery guarantees, retained messages enable state synchronization, and will messages handle offline notifications. MQTT 5.0 adds enterprise features such as session expiry and shared subscriptions.

Overview

MQTT (Message Queuing Telemetry Transport, 1999/2013) is the most concise pub/sub messaging protocol, specifically designed for low-bandwidth, high-latency, and unreliable IoT networks. Publishers do not connect directly to subscribers—all messages pass through a broker (Mosquitto/EMQX), and topics support wildcard filtering. QoS 0/1/2 provide three levels of delivery guarantees, while retained messages and will messages enable state synchronization and offline notifications. MQTT 5.0 (2019) adds enterprise features such as session expiry and shared subscriptions.

Model

MQTT is a minimalist pub/sub protocol designed for low-bandwidth, high-latency, and unreliable networks (IoT, M2M). All messages pass through a central broker (Mosquitto, EMQX):

Pub/Sub Model: Messages Distributed by Broker via Topic Filtering Temperature Sensor Publisher publish "home/bedroom/temp" 23.5 Broker Mosquitto / EMQX

→ Push to all matching subscribers

"home/bedroom/temp" Exact Match "home/+/temp" Single-level wildcard + "home/#" Multi-level wildcard # (including all sub-levels) The Broker only performs topic string matching and does not care about the message content; the + wildcard matches a single level, and # matches multiple levels and all sub-levels below.

QoS

QoS 0/1/2: Delivery Guarantees Achieved Through Handshakes QoS 0 At most once PUBLISH qos=0 Pub→Broker, no acknowledgment PUBLISH qos=0 Broker→Sub, no acknowledgment fire and forget No acknowledgment · No retry QoS 1 At least once PUBLISH qos=1,id=N Publisher→Broker PUBACK id=N Broker→Publisher · Acknowledged Possible duplicates retransmission QoS 2 Exactly once ①PUBLISH Pub→Broker ②PUBREC Broker→Pub ③PUBREL Pub→Broker ④PUBCOMP Broker→Pub No duplicates, no loss Four-way handshake confirmation The higher the QoS number, the more handshakes, the more reliable the delivery, but also the higher the latency and bandwidth overhead— MQTT leaves the choice to each message, rather than applying a one-size-fits-all global approach.

MQTT CONNECT/CONNACK

CONNECT:
  protocol_name: "MQTT" (v3.1.1) or "MQIsdp" (v3.1)
  protocol_level: 4 (v3.1.1) or 5 (v5.0)
  flags: clean_session, will_flag, will_qos, will_retain, password_flag, username_flag
  keep_alive: seconds (publisher must send PINGREQ within keep_alive seconds)
  client_id: unique ID (or empty → broker assigns, v5.0 only)
  [will_topic, will_message] ← if will_flag=1
  [username, password]

CONNACK:
  session_present: 0 (new session), 1 (existing session resumed)
  return_code: 0=success, 1-5=failure reason

Will Message

Declared when the client connects: "If I disconnect unexpectedly, the broker sends this message": CONNECT will_topic + will_message + will_retain. If the client disconnects abnormally (TCP close or keepalive timeout) → the broker publishes the will message.

MQTT 5.0 Improvements

  1. Session expiry: How long the session is retained after disconnection (QoS 1/2 messages in the queue continue)
  2. Message expiry: TTL for a single message
  3. Shared subscriptions: Load balancing among multiple subscribers (round-robin)
  4. Reason codes: All ACK messages include specific reasons
  5. Topic aliases: 1/2-byte aliases replace full topic names → saves bandwidth

References

  • broker: Eclipse Mosquitto (C), EMQX (Erlang), VerneMQ
  • tools: mosquitto_pub -h broker -t topic -m "hello", MQTT Explorer

Keywords: MQTT, pub/sub, QoS, retained, will, Mosquitto, IoT, topic filter

Related pages

© 2026 liz's doc