MeshCore Routing Architecture

MeshCore Routing Architecture

MeshCore uses a hybrid flood-then-direct routing scheme. Unlike a route-first protocol, MeshCore floods the first actual message to a destination; the path is recorded during that flood and returned to the sender, who then uses it for direct (path-based) routing on later messages. There is no separate route-establishment phase preceding data transmission.

Path Discovery Mechanism

Path discovery happens as a byproduct of the first message:

1. When Node A first messages Node D, it sends the message flood-routed (ROUTE_TYPE_FLOOD); there is no dedicated Route Request packet.
2. Each repeater that rebroadcasts the flooded message appends its short path hash (a 1-3 byte prefix of its public key), building a path record as the packet propagates.
3. When the flooded message reaches Node D, D sends a path-return packet (PAYLOAD_TYPE_PATH, optionally bundling an ACK) back to A along the reverse of the recorded path.
4. Node A receives the path-return and now has the learned path: A → B → C → D.

Path Caching

Learned paths are stored per contact. Subsequent messages to the same destination use the stored path directly (ROUTE_TYPE_DIRECT) without re-flooding, reducing overhead on established links.

Path Maintenance

MeshCore has no explicit Route Error (RERR) message. When a direct-routed message is not acknowledged, the original sender treats the path as failed and re-floods (resets the path to flood). Repeaters do not generate route-error control packets.

When a path fails (no ACK), the contact's path is reset to flood; the next message re-discovers a route, letting the network self-heal after topology changes.

Advantages Over Pure Flooding

• After a path is learned, only the repeaters on the stored path forward the message - significantly less airtime consumption for repeated unicast traffic.
• For repeated unicast traffic in a stable topology, MeshCore can use less channel capacity than flooding. Group/broadcast messages still flood, and unstable topologies erode the advantage. No specific node-count guarantee should be inferred.
• Repeater nodes can handle more traffic since they are not blindly rebroadcasting everything once paths are established.

Disadvantages

• The first message to a new destination floods the mesh, adding airtime and latency before a path is learned.
• Stored paths require memory on each node.
• Topology changes can invalidate a learned path, requiring a re-flood. A single learned path provides no redundancy, so there is a silent dead-window until the stale path triggers a re-flood.

Forwarding vs. Endpoint Roles

MeshCore's roles are Companion, Repeater, Room Server, and Sensor - not a clean two-way split. Forwarding behavior differs by role:

• Repeater (and Room Server) nodes: participate in forwarding and carry the network's routing load.
• Companion (client) and Sensor nodes: generate and receive messages but do not forward traffic for others. (The firmware term is "Companion"; the app/CLI labels contact type 1 "client".)

Because clients never relay, a deployment with only client nodes provides no multi-hop coverage - it is point-to-point only. At least one repeater or room-server is required for any node-to-node relaying. Plan repeater infrastructure before relying on the network.