Both protocols move a message from a device across a lossy link, but they define "reliable" differently:
MQTT QoS 0 — fire-and-forget: PUBLISH, no ack. Lost = lost.
MQTT QoS 1 — at-least-once: PUBLISH → wait PUBACK.
No PUBACK in time ⇒ resend PUBLISH (dup flag).
Broker may store/forward duplicates.
MQTT QoS 2 — exactly-once: 4-way handshake
PUBLISH → PUBREC → PUBREL → PUBCOMP,
each leg retried independently until acked.
CoAP NON — non-confirmable: fire-and-forget, like QoS 0.
CoAP CON — confirmable: client resends the whole CON
request if no ACK arrives, waiting
t = ACK_TIMEOUT × 2^retries (exponential backoff),
up to MAX_RETRANSMIT attempts (RFC 7252 default 4).
Each leg in this sim independently rolls the configured packet-loss probability p. The broker/server only fans a message out to subscriber devices once it has actually received it — that fan-out uses its own independent loss rolls, shown as Fan-out delivery.
- QoS/Type buttons — choose the delivery guarantee for the next messages.
- Packet loss slider — the per-hop drop probability of the simulated link.
- Send Message / Auto — fire one message, or auto-fire on the interval slider.
Real-world relevance: MQTT (broker-based publish/subscribe) drives most cloud telemetry pipelines; CoAP (peer request/response over UDP) is built for constrained radios like 6LoWPAN and LoRaWAN where a persistent TCP session is too expensive.