The MOSH transport layer is responsible for moving MOSH frames between physical transports, fragmenting large messages, reassembling inbound fragments, and deciding whether a frame should be processed locally or forwarded to another link.
In the current implementation, the transport layer supports both a data plane and a control plane.
A MOSH transport can currently operate in one of these modes:
The intended meanings are:
The transport layer separates two concerns:
This lets a device act as:
The control plane uses:
The control plane is intended for:
Control-plane routing is based on control node ID, not on data network ownership.
Each control-plane destination is represented by a control route entry.
A control route defines:
Example conceptually:
The data plane uses:
The data plane is intended for normal MOSH network traffic.
Data-plane routing is based on network ownership.
Each data route defines:
Example conceptually:
The current transport manager contains two explicit routing tables:
Each control route entry contains:
If `local == true`:
If `local == false`:
Each data route entry contains:
If `nativeTransport != null`:
If `nativeTransport == null`:
The transport manager currently maintains:
The TX queue contains logical outbound frames generated locally by the MCU.
When processed:
The RX queue contains inbound logical frames that are ready for local processing.
A frame reaches the RX queue only after:
`MOSH_Core` drains this RX queue and performs higher-level protocol handling.
The MOSH wire protocol currently uses a maximum encoded frame size of:
That full encoded frame contains:
This means the maximum single-frame payload is:
Any logical payload larger than that must be fragmented.
When a frame is fragmented, the fragment payload begins with a 4-byte fragment header:
The remaining bytes are fragment data.
Inbound fragments are stored in a reassembly buffer keyed by:
A complete logical frame is delivered only when:
Expired fragment sets are discarded after the configured timeout.
The transport layer now distinguishes between local delivery and forwarding.
If an inbound frame is on control network `0`:
If an inbound frame is on a non-zero data network:
The current implementation still keeps a compatibility fallback for cases where explicit routing-table entries have not yet been registered.
If no explicit data or control route is found:
This is useful during transition, but the preferred long-term model is to explicitly populate control and data route tables.
TTL is now managed consistently.
This applies to:
If a frame has `TTL = 0` at the moment it would need to be forwarded:
Local delivery does not decrement TTL.
`HOST_BACKED` mode is intended for the case where a bridge controls one or more radios through attached MCUs.
In this model:
This allows one MCU to act as:
The current transport manager exposes APIs for registering route ownership:
These APIs are also exposed through `MOSH_Core`.
They are intended to describe the topology explicitly, for example:
The current transport layer is functional, but still evolving.
Known limitations include:
The next planned step is to allow MOSH radios to exchange control-plane MOSH messages that advertise or discover remote data-network ownership.
That would allow routing tables to be learned dynamically rather than fully hard-coded.