Application Protocols · Study deck

CoAP and MQTT: Brokers and Selection Evidence

A protocol is a set of rules for sending messages.

Broker Bex is your guide for this deck.

coapmqttcomparison
iotclass.org

After studying this chapter

Learning objectives

You will be able to:

  • Explain: The team must decide whether a broker, a service that passes messages, should keep session and delivery state, or whether endpoints, the devices at each end, should talk directly.
  • Explain: The direct side removes that hop and can reduce latency, but each client must know endpoints and own retry, discovery, and repeated delivery.
  • Explain: The point is not merely to count hops, but to expose which component owns discovery, fan-out, retry, and offline delivery.
  • Explain: The hybrid path keeps constrained CoAP exchanges local and makes the gateway validate, translate, buffer, and publish into MQTT.
iotclass.org

Major section

Start With the Situation

A protocol is a set of rules for sending messages.

  • Two protocols can meet the payload budget, the limit on data in each message, and the energy budget.
  • Yet they can put responsibility in different places.
  • The team must decide whether a broker, a service that passes messages, should keep session and delivery state, or whether endpoints, the devices at each end, should talk directly.
iotclass.org

Major section

Tradeoff: Broker-Based (MQTT) vs Direct Communication (CoAP/HTTP)

The point is not merely to count hops, but to expose which component owns discovery, fan-out, retry, and offline delivery.

  • Tradeoff: the broker becomes critical infrastructure and adds one extra hop.
  • Tradeoff: clients must handle retries, discovery, and repeated fan-out themselves.

Why it matters

The direct side removes that hop and can reduce latency, but each client must know endpoints and own retry, discovery, and repeated delivery.

Direct CoAP, broker-mediated MQTT, and a hybrid CoAP-to-MQTT gateway create different ownership and recovery boundaries.
Direct CoAP, broker-mediated MQTT, and a hybrid CoAP-to-MQTT gateway create different ownership and recovery boundaries.
iotclass.org

Major section

Tradeoff: Broker-Based (MQTT) vs Direct Communication (CoAP/HTTP) (continued)

The hybrid path keeps constrained CoAP exchanges local and makes the gateway validate, translate, buffer, and publish into MQTT.

  • That third route is not a free compromise: the gateway becomes an explicit reliability and operations boundary.
  • The selection bullets below should therefore be read as ownership choices, not protocol popularity.
  • The direct side removes that hop and can reduce latency, but each client must know endpoints and own retry, discovery, and repeated delivery.
iotclass.org

Major section

Summary

CoAP uses UDP with request-response pattern; MQTT uses TCP with publish-subscribe.

  • CoAP has 4-byte minimum header; MQTT has 2-byte minimum header (plus TCP overhead).
  • CoAP offers optional reliability (CON/NON); MQTT provides QoS 0/1/2 levels.
  • A hybrid can use both.
  • Factor in existing ecosystem and tooling support for your platform.
iotclass.org

Deck summary

Key takeaways

A protocol is a set of rules for sending messages.

  • The point is not merely to count hops, but to expose which component owns discovery, fan-out, retry, and offline delivery.
  • The hybrid path keeps constrained CoAP exchanges local and makes the gateway validate, translate, buffer, and publish into MQTT.
  • CoAP uses UDP with request-response pattern; MQTT uses TCP with publish-subscribe.
iotclass.org

Retrieval practice

Recall check 1 of 5

Broker Bex says: answer from memory, then check your reasoning.

Q1Why might a system use BOTH CoAP (edge) and MQTT (cloud) in hybrid architecture?

ADuplicate paths that carry the same traffic if one protocol fails
BCoAP for encrypted messages; MQTT for plaintext dashboard delivery
CStandards rule that every IoT design must use both protocols
DCoAP at the edge; MQTT for broker fan-out to cloud consumers
Show answer

Answer: D Explanation: Hybrid architectures leverage protocol strengths: (1) Edge: CoAP for battery sensors → gateway (minimal power, direct queries), (2) Cloud: Gateway translates to MQTT → cloud services (pub-sub scalability, cloud platform integration).

iotclass.org

Retrieval practice

Recall check 2 of 5

Broker Bex says: answer from memory, then check your reasoning.

Q2A factory sends direct alerts from 200 pressure sensors over a link with 5% packet loss. Which configuration provides an acknowledgment and retry for a one-shot alert? The separate safety design must still meet the <100 ms action deadline under loss.

ACoAP CON with retransmission for reliable alerts
BCoAP NON messages (non-confirmable) for lowest latency
CMQTT QoS 2 (exactly-once) for strongest delivery semantics
DHTTP polling every 50ms for real-time updates
Show answer

Answer: A CON provides CoAP acknowledgment and retransmission, making it the best of these direct alert options.

iotclass.org

Retrieval practice

Recall check 3 of 5

Broker Bex says: answer from memory, then check your reasoning.

Q3What is the most fundamental architectural difference between MQTT and CoAP?

AMQTT is encrypted by default; CoAP traffic is always plaintext.
BMQTT is broker pub/sub over TCP; CoAP is REST-style over UDP.
CCoAP has no acknowledgment mode; MQTT is always reliable.
DThey are identical protocols except for application header size.
Show answer

Answer: B MQTT maintains a standing TCP connection to a broker that routes publishes to subscribers; CoAP exchanges independent UDP datagrams in a request/response style, with Observe for push.

iotclass.org

Retrieval practice

Recall check 4 of 5

Broker Bex says: answer from memory, then check your reasoning.

Q4A battery sensor reports once every 5 minutes and never needs commands pushed to it. Why does CoAP typically use less energy than MQTT here?

ACoAP payload fields are always smaller than MQTT payload fields.
BMQTT cannot run on devices powered by batteries at all.
CCoAP avoids TCP setup and keepalives between infrequent reports.
DCoAP never needs acknowledgment packets for reliable delivery.
Show answer

Answer: C For infrequent reporting, the connection cost dominates.

Q5What maps CoAP resource exchanges into MQTT publications and subscriptions?

ATranslation Gateway
BConstrained CoAP Resource
CMQTT Broker and Subscribers
Show answer

Answer: A The gateway deliberately maps CoAP resource requests and responses into MQTT topics, publications, and subscription expectations.

iotclass.org

Retrieval practice

Recall check 5 of 5

Broker Bex says: answer from memory, then check your reasoning.

Q6Complete the CoAP request (left) equivalent to an MQTT publish (right) for sending temperature data:

Arequest = Message(code=PUT, uri='coap://gateway/sensors/temp01')
Brequest = Message(code=POST, uri='mqtt://gateway/sensors/temp01')
Crequest = Message(code=PUBLISH, uri='coap://gateway/sensors/temp01')
Drequest = Message(code=GET, uri='coap://gateway/sensors/temp01')
Show answer

Answer: A CoAP uses RESTful methods (PUT) with resource URIs while MQTT uses publish() with topic strings.

iotclass.org

Print reference

Answers 1 of 2

Answer key.

  1. D · Explanation: Hybrid architectures leverage protocol strengths: (1) Edge: CoAP for battery sensors → gateway (minimal power, direct queries), (2) Cloud: Gateway translates to MQTT → cloud services (pub-sub scalability, cloud platform integration).
  2. A · CON provides CoAP acknowledgment and retransmission, making it the best of these direct alert options.
  3. B · MQTT maintains a standing TCP connection to a broker that routes publishes to subscribers; CoAP exchanges independent UDP datagrams in a request/response style, with Observe for push.
iotclass.org

Print reference

Answers 2 of 2

Answer key.

  1. C · For infrequent reporting, the connection cost dominates.
  2. A · The gateway deliberately maps CoAP resource requests and responses into MQTT topics, publications, and subscription expectations.
  3. A · CoAP uses RESTful methods (PUT) with resource URIs while MQTT uses publish() with topic strings.
iotclass.org