Skip to content

Commit 2a178cd

Browse files
GitGab19GitGab19
authored
Merge pull request #118 from plebhash/clarify-framing
clarify framing section
2 parents 67fcb8f + 62899f4 commit 2a178cd

File tree

1 file changed

+13
-2
lines changed

1 file changed

+13
-2
lines changed

‎03-Protocol-Overview.md

+13-2
Original file line numberDiff line numberDiff line change
@@ -92,11 +92,22 @@ The message framing is outlined below:
9292

9393
| Field Name | Type | Description |
9494
| -------------- | ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
95-
| extension_type | U16 | Unique identifier of the extension describing this protocol message. <br>Least significant bit (i.e.bit 15, 0-indexed, aka channel_msg) indicates a message which is specific to a channel, whereas if the most significant bit is unset, the message is to be interpreted by the immediate receiving device. <br>Note that the channel_msg bit is ignored in the extension lookup, i.e.an extension_type of 0x8ABC is for the same "extension" as 0x0ABC. <br>If the channel_msg bit is set, the first four bytes of the payload field is a U32 representing the channel_id this message is destined for (these bytes are repeated in the message framing descriptions below). <br>Note that for the Job Declaration and Template Distribution Protocols the channel_msg bit is always unset. |
96-
| msg_type | U8 | Unique identifier of the extension describing this protocol message |
95+
| extension_type | U16 | Unique identifier of the extension associated with this protocol message |
96+
| msg_type | U8 | Unique identifier of this protocol message |
9797
| msg_length | U24 | Length of the protocol message, not including this header |
9898
| payload | BYTES | Message-specific payload of length msg_length. If the MSB in extension_type (the channel_msg bit) is set the first four bytes are defined as a U32 "channel_id", though this definition is repeated in the message definitions below and these 4 bytes are included in msg_length. |
9999

100+
### 3.2.1 Routing Frames over Channels
101+
102+
Some bits of the `extension_type` field can also be repurposed for signaling on how the frame should be handled across channels.
103+
104+
The least significant bit of `extension_type` (i.e., bit 15, 0-indexed, also known as `channel_msg`) indicates a message which is specific to a channel, whereas if the most significant bit is unset, the message is to be interpreted by the immediate receiving device.
105+
106+
Note that the `channel_msg` bit is ignored in the extension lookup, i.e., an `extension_type` of `0x8ABC` is for the same "extension" as `0x0ABC`.
107+
108+
If the `channel_msg` bit is set, the first four bytes of the payload field is a `U32` representing the `channel_id` this message is destined for (these bytes are repeated in the message framing descriptions below).
109+
110+
Note that for the Job Declaration and Template Distribution Protocols the `channel_msg` bit is always unset.
100111

101112
## 3.3 Reconnecting Downstream Nodes
102113

0 commit comments

Comments
 (0)