Offline Apiary Data Relay: Store-and-Forward Sync (2D)

Route

Relay speed 8.0 km/h

Apiaries on round 5

Dwell time per stop 30 s

Data & Buffers

Hive data-generation rate 6 rec/h

Hive buffer capacity 20 rec

Sync transfer rate 2.0 rec/s

Relay carry capacity 40 rec

Live Readout

Sim. elapsed

0:00

Relay carrying

0 rec

Generated

Delivered

Lost (buffer full)

0 (0.0%)

Avg. delivery latency

0 min

How it works

This is a store-and-forward delay-tolerant network (DTN), the same idea behind offline field-record apps: each hive is a sensor node with no direct link to the internet. It buffers readings locally in a FIFO queue. A single mobile relay (the beekeeper) tours the hives on a loop, and while parked at a hive for the dwell time it drains that hive's queue at a fixed sync rate:

transferred(Δt) = min( hive.queue, relay.free_space, xferRate·Δt )
hive.queue -= transferred;  relay.queue += transferred

Nothing uploads to the cloud until the relay physically returns to the signal mast (the base station) — then the whole carried queue flushes at once, and each record's delivery latency is measured from the moment it was generated at its hive:

latency(record) = t_delivered − t_generated

If a hive's queue is already full when a new reading is due, the reading is dropped (tail-drop) — real buffer loss, not decoration. Two independent bottlenecks can cause it: the buffer capacity is too small for the round-trip time, or the sync rate × dwell time isn't enough to drain a hive before the relay has to move on, so backlog compounds cycle after cycle.

Hive fill ring — amber-to-red as a hive's buffer approaches capacity.
Relay speed / dwell time — control the cycle length that limits both latency and how much backlog any hive can accumulate.
Sync rate / relay capacity — control whether a stop actually clears a hive's backlog or leaves a remainder for next lap.

Relay (beekeeper) Hive buffer (amber = fuller) Signal mast / base