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:
@@ -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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user