Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013kj58Jugkic783b8ZrtTVZ
2.3 KiB
type
| type |
|---|
| default |
Initial plan
The scope question, first
This started as "aggregator and pusher to the tablet over USB". The pushing part may not need to exist: over USB the tablet has an IP link via RNDIS, and the architecture already says Class B devices reaching the bus over IP connect to the broker directly. A Flutter MQTT client can talk to mosquitto with no hop in between.
What does not go away:
| Job | Why it needs a gateway |
|---|---|
| Aggregation | Raw CAN at 500 kbps must never reach a display; something has to downsample |
| Nav HTTP proxy | Route requests are request/response and fit MQTT badly |
| Static assets | Serving the PMTiles basemap to the display |
| Non-IP transports | BT SPP and plain serial for ESP32 clients have no broker access |
So: build the aggregation and the HTTP surface. Do not build a telemetry relay for clients that can already subscribe for themselves.
Order
- Static file serving for the basemap — smallest useful thing, unblocks the map.
- Nav HTTP proxy to svc-nav.
- Aggregation and rate limiting, once there is real CAN traffic to aggregate.
- Serial bridge, when an ESP32 client exists.
Two roles in one process
This is both the local aggregation hub and the app gateway. That is allowed because the hub holds no durable state — it is rebuilt from retained topics on restart — but it holds only while these rules do:
- Steady state is reached with zero clients connected. Nothing in aggregation waits on a display.
- The boundary is drop-only: bounded per-client queues, drop oldest, never block. A tablet with its screen off must not stall aggregation.
- Backpressure never propagates inward. Drop at the boundary; never slow the bus subscription to match a slow client.
- Per-client state is per-connection and never touches the aggregate.
The point of the rules is that the seam stays visible. If the gateway ever needs to be a separate process, that becomes a refactor rather than a rewrite.
Links
| Link | Shape | Initiator |
|---|---|---|
| Vehicle and nav state topics | subscribe | — |
| Command topics | publish | — |
| Downstream to app | simplex push stream, lossy-tolerant | app connects |
| Upstream from app | simplex request/response, acknowledged | app |
| Route requests onward | request/response, HTTP | this service |