Skip to content
Free public beta until December 4, 2026: every course is open, no card needed. After that, the first chapter of each course stays free and full access is a one-time $39 ($19 for up to 100 founding members chosen for helpful feedback). Your progress is kept. How the beta works

Every way a device stays connected

Noticing the link is gone, getting back on without a stampede, keeping data meanwhile, and not doing anything twice. Each is a separate mechanism, and a robust device needs all four.

A connection will fail; the question is which part of surviving it you're designing. Work through them in order.

  • Noticing it's gone. A TCP connection can die without either end being told. MQTT's keepalive bounds the delay to 1.5k seconds; a heartbeat or the last will tells everyone else. If someone must know within a minute, the keepalive is your setting.
  • Getting back on. Reconnect with exponential backoff, a cap and jitter, so a short glitch costs a second and a long outage settles into rare attempts, and a thousand devices don't return in the same second. BLE links have their own version of this.
  • Not losing data meanwhile. On the device, an offline queue (store and forward) with a stated drop policy. On the broker, a persistent session that queues QoS 1 and 2 messages for a client that comes back under the same ID. For the latest value only, a retained message.
  • Not doing anything twice. Resending after an outage means some messages arrive twice. A message ID or correlation ID and an idempotent handler turn at-least-once delivery into exactly-once effects.
  • Proving it works. Test it under a bad network on purpose, not by waiting for one.

Noticing the link is gone

The failure modes, and the detection delay before anyone notices.

See section →
How long it takes a device to notice that its connection is gone.

Term

keepalive

See section →
The longest a client promises to stay silent; it sends a ping if it has nothing else to say.

Example

With k = 60 s, a device that loses power is declared gone, and its will sent, at most 1.5 \times 60 = 90 s after its last packet.

Term

last will

See section →
A message a client leaves with the broker in advance, which the broker publishes for it if the client disappears without saying goodbye.

Term

heartbeat

See section →
A small message a device sends on a schedule just to say it is still alive.

Getting back on

Waits of base × factorⁿ, capped, with jitter.

See section →
Waiting longer after each failed retry, usually doubling the wait each time.

Example

Base 1 s, factor 2: attempts at 1, 3, 7, 15 and 31 s after the outage is noticed.
See section →
The longest a device will ever wait between retries.

Term

jitter

See section →
A random amount added to or taken from a retry wait so many devices don't retry at the same instant.
See section →
Thousands of devices all reconnecting at the same moment and overwhelming the server.

The same problem on a BLE link, with its own supervision timeout.

Not losing data meanwhile

An offline queue on the device, sized in RAM or flash, with a drop policy.

See section →
The fixed-size buffer where a device keeps readings it couldn't send yet.
See section →
The rule for which message to throw away when the offline queue is full.

A persistent session keeps subscriptions and queues QoS 1 and 2 messages for a client that returns under the same ID.

See section →
A connection where the broker remembers the client's subscriptions and saves QoS 1 and 2 messages for it while it is offline.
See section →
A message the broker keeps and hands to anyone who subscribes later, so they get the last known value at once.

Not doing anything twice

Message IDs that survive a restart, and handlers that skip repeats.

See section →
Each message is resent until it is confirmed, so it always arrives but may arrive twice.

Term

idempotent

See section →
Safe to do twice: doing it again changes nothing.

Example

"Set the valve to 50 %" is safe to run twice; "add 50 ml" is not.

Term

message ID

See section →
A number or string that uniquely names one message so a receiver can spot a repeat.
See section →
A label a command carries so its reply can be matched back to it.

Proving it works

Loss, delay and outages made on purpose, so recovery is tested before the field tests it.

See section →
Deliberately adding loss, delay or outages to a network so you can test how software copes.