Simplify frame header to message_type + payload_length (6 bytes)

Removes channel_id from the header. All message-specific identifiers
(stream_id, request_id, etc.) now live at the start of the payload,
interpreted by each message type handler. A relay seeing an unknown
type can skip or forward it using only payload_length, with no
knowledge of the payload structure.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
2026-03-26 22:00:43 +00:00
parent ff48559b12
commit 197ab7d5db
4 changed files with 30 additions and 27 deletions

View File

@@ -126,20 +126,23 @@ Header fields:
| Field | Size | Purpose |
|---|---|---|
| `message_type` | 2 bytes | Distinguishes video frame, control request, control response |
| `channel_id` | 2 bytes | For video: identifies the stream. For control: identifies the request/response pair (correlation ID) |
| `message_type` | 2 bytes | Determines how the payload is interpreted |
| `payload_length` | 4 bytes | Byte length of the following payload |
**Message types:**
The header is intentionally minimal. Any node — including a relay that does not recognise a message type — can skip or forward the frame by reading exactly `payload_length` bytes without needing to understand the payload. All message-specific identifiers (stream ID, correlation ID, etc.) live inside the payload and are handled by the relevant message type handler.
| Value | Meaning |
|---|---|
| `0x0001` | Video frame |
| `0x0002` | Control request |
| `0x0003` | Control response |
| `0x0004` | Stream event |
**Message types and their payload structure:**
Video frame payloads are raw compressed frames. Control payloads are binary-serialized structures — see [Protocol Serialization](#protocol-serialization). Stream events carry lifecycle signals for a channel — see [Device Resilience](#device-resilience).
| Value | Type | Payload starts with |
|---|---|---|
| `0x0001` | Video frame | `stream_id` (u16), then compressed frame data |
| `0x0002` | Control request | `request_id` (u16), then command-specific fields |
| `0x0003` | Control response | `request_id` (u16), then result-specific fields |
| `0x0004` | Stream event | `stream_id` (u16), `event_code` (u8), then event-specific fields |
Node-level messages (not tied to any stream or request) have no prefix beyond the header — the payload begins with the message-specific fields directly.
Control payloads are binary-serialized structures — see [Protocol Serialization](#protocol-serialization). Stream events carry lifecycle signals — see [Device Resilience](#device-resilience).
### Unified Control and Video on One Connection