Application Protocols · Study deck
CoAP and MQTT: Overhead and Reliability
This first route compares the protocols from message flow through transport, reliability, packet overhead, and energy arithmetic.
Broker Bex is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Compare Architecture Models: Distinguish between CoAP's request-response and MQTT's publish-subscribe patterns, explaining the coupling implications of each
- Evaluate Transport Trade-offs: Analyze UDP vs TCP implications for IoT deployments, justifying which is appropriate given device constraints and reliability needs
- Assess QoS Options: Compare reliability mechanisms in both protocols and select the appropriate QoS level for a given use case
- Calculate Protocol Overhead: Compute header sizes, per-message bandwidth, and annual energy expenditure to demonstrate efficiency trade-offs between CoAP and MQTT
Major section
In 60 Seconds
An application protocol is a shared set of rules for exchanging messages.
- The Constrained Application Protocol (CoAP) lets one device ask another device for data or an action.
- It sends each exchange with the User Datagram Protocol (UDP).
- UDP does not keep a connection open.
- CoAP also helps a client find the resources that a device offers.
Major section
In 60 Seconds (continued)
Telemetry means measurements or status reports sent by a device.
- Message Queuing Telemetry Transport (MQTT) lets senders publish those reports for many listeners.
- It uses the Transmission Control Protocol (TCP).
- TCP keeps an ordered connection open.
- A broker is the service that receives each MQTT message and sends it to the right listeners.
Major section
Key Concepts
MQTT means Message Queuing Telemetry Transport and uses publish and subscribe.
- A: Broker routes messages from senders to matching listeners.
- A: Topic is a name such as home/bedroom/temperature that selects those listeners.
- A: Retained Message is the last topic message stored for a new listener.
Major section
For Beginners: CoAP vs MQTT
CoAP and MQTT are two popular IoT communication protocols with different strengths.
- MQTT is like a radio broadcast -- a central broker distributes messages to subscribers.
- CoAP is like a web request -- devices directly ask each other for information.
- Choosing between them depends on your network setup, device resources, and communication patterns.
Major section
The Great Protocol Debate
MQTT is better when you have unreliable connections and need the broker to buffer messages.
- "I use MQTT to report my temperature readings," said Temperature Terry. "Why would anyone use CoAP instead?".
- With: MQTT, I have to go through a broker -- like posting on a bulletin board and hoping someone reads it.".
- CoAP is better when you want fast, direct request-response -- like asking a sensor 'what's your temperature right now?'".
Major section
The Great Protocol Debate (continued)
the LED jumped in: "Because I don't need a middleman!
- "But the broker is useful!" argued Sammy. "If the dashboard app is offline, the broker holds my messages until it comes back.
- the battery settled the debate: "For my power budget, CoAP wins when I only need occasional readings -- one request, one response, done.
- But MQTT wins when I need continuous updates pushed to me without asking every time.
Major section
CoAP vs MQTT: Detailed Comparison
Choosing between CoAP and MQTT is not always straightforward.
- CoAP begins with request-response between known endpoints, whereas MQTT inserts a broker so publishers and subscribers need not know one another.
Major section
Format Discovery: CoAP Negotiates, MQTT Assumes
The "Discovery" row above is about finding a resource.
- A separate question is whether the two endpoints agree on what format that resource is returned in, and the two protocols answer it differently.
- CoAP carries Content-Format and Accept options in its header, so a client can ask which representations a server can return, and the server can label the format it sends back.
- MQTT has no equivalent metadata field.
Major section
Putting Numbers to It: CoAP vs MQTT Packet Overhead
Scenario:: A sensor sends a 10-byte temperature reading every 60 seconds for 1 year.
- The estimate uses decimal megabytes and treats the MQTT TCP acknowledgment as radio-on airtime under the same 250 kbps link budget.
- One year at a 60-second interval is 365 x 24 x 3600 / 60 = 525,600 messages.
- For a measured device budget, split transmit, receive, idle-listen, retries, and connection setup into separate states.
Major section
Putting Numbers to It: CoAP vs MQTT Packet Overhead (continued)
CoAP traffic is 525,600 x 68 = 35,740,800 bytes, or 35.7 MB using 1 MB = 1,000,000 bytes.
- MQTT traffic is 525,600 x 154 = 80,942,400 bytes, or 80.9 MB on the same decimal basis.
- The byte reduction is 80,942,400: 35,740,800 = 45,201,600 bytes, so the saving is 45,201,600 / 80,942,400 = 0.558, about 56%.
- MQTT airtime is 154 x 8 / 250,000 = 0.004928 s; at the same power, that is 49.28 uJ.
Major section
Tradeoff: HTTP vs MQTT vs CoAP
Best for constrained nodes that need direct request-response or Observe semantics.
- Tradeoff: reliability is optional, so the application must choose CON/NON behavior intentionally.
- Debugging and development simplicity is priority.
- Bandwidth and battery constraints are not critical (Wi-Fi/Ethernet devices).
- Many devices need to publish to or subscribe from a central system.
Deck summary
Key takeaways
An application protocol is a shared set of rules for exchanging messages.
- Telemetry means measurements or status reports sent by a device.
- MQTT means Message Queuing Telemetry Transport and uses publish and subscribe.
- CoAP and MQTT are two popular IoT communication protocols with different strengths.
- MQTT is better when you have unreliable connections and need the broker to buffer messages.
Retrieval practice
Recall check
Broker Bex says: answer from memory, then check your reasoning.
Q1A battery-powered soil sensor needs to reliably deliver a daily report once per day. Packet loss on the network is 2%. Which protocol and QoS configuration best balances reliability and battery life?
Show answer
Answer: B For infrequent, reliability-required messages on battery devices, CoAP CON is the optimal choice: it provides application-layer retransmission over connectionless UDP, eliminating TCP keepalive overhead while ensuring delivery even with moderate packet loss.
Print reference
Answers
Answer key.
- B · For infrequent, reliability-required messages on battery devices, CoAP CON is the optimal choice: it provides application-layer retransmission over connectionless UDP, eliminating TCP keepalive overhead while ensuring delivery even with moderate packet loss.