Offline Time Is the Unbounded Term

Offline Time Is the Unbounded Term

Ada re-derives this chapter’s own numbers step by step, at full precision

foundations
math-foundations
calculation-audit
mqtt
Ada ADA · CALCULATION AUDIT

Offline Time Is the Unbounded Term

A persistent MQTT session queues every message a sleeping client misses, and each one costs about 100 bytes of payload plus 40 bytes of broker metadata — 140 bytes. A sensor offline for one hour at one message a minute piles up about 8 KB; across 1000 sensors that is 8.4 MB. This audit makes the growth law explicit to show that offline time, not message size, is the unbounded term.

Companion to the chapter MQTT Session Management — every number here comes from that chapter.

See the relationship before changing it

The figure reads from left to right. The blue card is offline duration. The middle card applies the page rule. The green card is queue per sensor. Walk the arrows once: set the input, apply the rule, then read the result with its unit.

Offline duration changes queue per sensor An input card leads through the rule queue = offline minutes x 140 bytes/message to the queue per sensor result. INPUT PAGE INPUT APPLY THE RULE predict calculate check units OUTPUT RESULT
Walk the arrows. Without expiry, memory grows for as long as the client stays offline.

Derive the baseline in four named moves

  1. 1

    Name the input. The chapter baseline is 60 minutes.

  2. 2

    Name the relationship. queue = offline minutes x 140 bytes/message

  3. 3

    Substitute with units. 60 x 140 = 8,400 bytes

  4. 4

    Read the result. Keep the unit beside the value. Use it only inside the technical boundary on this page.

Predict, then change offline duration

Try Predict the direction of queue = offline minutes x 140 bytes/message. Test another offline duration, then compare queue per sensor.

60 minutes
Chapter baseline
Queue per sensor

Observe Without expiry, memory grows for as long as the client stays offline. Reset offline duration to 60 and compare queue per sensor.

Explain Without expiry, memory grows for as long as the client stays offline.

Check yourself

What should you do before trusting a moved-control result?
Answer: Predict its direction, apply the shown relationship, keep the units, and reset to the worked baseline.
What does this small model leave out?
Answer: Only offline duration moves here. Field effects named in the technical boundary stay fixed.
TryRecompute One hour offline at 1 msg/min: 60 x 140 = 8,400 bytes, about 8.4 KB per sensor.
ObserveTrack The same across 1000 sensors: 1000 x 8,400 = 8,400,000 bytes = 8.4 MB.
ExplainExplain Ten thousand sensors offline for that day: 10,000 x 201,600 = 2,016,000,000 bytes = 1.88 GiB.

Ready: use the stated baseline inputs, then compare each displayed result.

Ada: This section shows queue memory growing with the offline window, and I want to make the growth law explicit, because it is what turns a persistent session from a convenience into a broker-memory liability. Every queued message costs M_payload + M_overhead = 100 + 40 = 140 bytes.

  • One hour offline at 1 msg/min: 60 x 140 = 8,400 bytes, about 8.4 KB per sensor
  • The same across 1000 sensors: 1000 x 8,400 = 8,400,000 bytes = 8.4 MB
  • One day offline: 1440 x 140 = 201,600 bytes, about 197 KiB per sensor
  • Ten thousand sensors offline for that day: 10,000 x 201,600 = 2,016,000,000 bytes = 1.88 GiB

The only thing that changed between 8.4 KB and 197 KB is the message count, which is just offline minutes: 1440 / 60 = 24x longer offline gives 24x the memory, with no ceiling. That is why message expiry matters, since capping delivery to a one-hour window pins each sensor back to 60 x 140 = 8,400 bytes no matter how long it actually sleeps. The design choice is not whether to queue, but whether to bound the queue: without an expiry the broker’s RAM is hostage to the longest disconnection any single client can suffer.

Every number above is taken from the chapter’s own material and re-derived step by step.

Technical boundaries. This storage model deliberately does not simulate reconnect probability, expiry policies, duplicate delivery, or subscriber processing. Queue growth is the fixed publish rate multiplied by outage duration and message size.