How does a message cross a mesh network?

Before anything can be relayed, each device needs to know who is in range. Radios such as Bluetooth Low Energy do this with advertising: a device broadcasts small packets at intervals, and devices scanning nearby hear them. On a local IP network, devices can announce themselves with a discovery protocol such as multicast DNS.

The result is a list of direct neighbours. It changes constantly as devices move, sleep, or go out of range, so a mesh has to keep listening rather than discover once.

There are two broad approaches, and many real systems mix them.

Flooding. The sender broadcasts the message to every neighbour, and each node that hears it for the first time broadcasts it again. Flooding needs no map of the network and finds a path if one exists, which makes it tolerant of devices that move quickly. The cost is that many nodes transmit every message, so it uses more airtime and battery as the network grows. Bluetooth Mesh uses a managed form of flooding, in which only nodes with the relay feature enabled pass messages on.

Routing. Nodes learn which neighbour leads toward which destination and send each message along one path. Proactive protocols such as OLSR (RFC 3626) keep routes up to date all the time. Reactive protocols such as AODV (RFC 3561) look for a route only when there is something to send. Routing uses far less airtime, but it depends on fresh knowledge of the network, which is harder to keep when devices are moving.

In a mesh, the same message can reach a node more than once, by different paths. Without limits it could circle forever. Two mechanisms stop that.

• A hop limit. The sender sets a time to live (TTL), a count that each relay lowers by one. When it reaches zero, the message is not forwarded again. It is the same idea as the time to live field in an IPv4 header (RFC 791) and the hop limit in IPv6 (RFC 8200).
• Duplicate suppression. Every message carries a unique identifier. Each node remembers the identifiers it has handled recently and drops any copy it has already seen.

The hop limit also sets how far a message can travel. A higher limit reaches further but lets each message use more of the network, so it is a trade-off rather than a setting to maximise.

Radio links lose packets, and a relay can walk out of range halfway through a route. A mesh that only forwards and forgets gives the sender no idea whether anything arrived. Reliable meshes add acknowledgments: the recipient sends a small confirmation back, and the sender retries if none arrives within a timeout, usually waiting longer before each attempt. This is called exponential backoff. Because retries create more copies, they rely on duplicate suppression so that the recipient handles the message once.

When there is no path at all, a mesh can hold the message and try later instead of failing. That is store-and-forward.

As one concrete example, the Offline Protocol mesh SDK documents these defaults for version 0.27.0: messages start with a TTL of 8 hops, an acknowledgment times out after 10 seconds, a message is retried up to 10 times with backoff from 1 to 300 seconds, and each device remembers 2,000 message identifiers for 24 hours.

Every relay handles the message, so its content needs protection that does not depend on trusting the relays. With end-to-end encryption, only the sender and the recipient hold the keys; relays see ciphertext plus the little routing information they need to pass it on. Signatures let the recipient check who sent the message and that nothing changed in transit.

Delivery is also not the same as success. An acknowledgment says the message reached the recipient’s device. Whether the app on that device stored it, or a backend later accepted it, are separate questions that the application has to answer for itself.