# 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.