Skip to content

Commit 62899f4

Browse files
plebhashShourya742
andcommitted
clarify framing
Co-authored-by: bit-aloo <[email protected]>
1 parent 52e1fa2 commit 62899f4

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
@@ -96,11 +96,22 @@ The message framing is outlined below:
9696

9797
| Field Name | Type | Description |
9898
| -------------- | ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
99-
| 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. |
100-
| msg_type | U8 | Unique identifier of the extension describing this protocol message |
99+
| extension_type | U16 | Unique identifier of the extension associated with this protocol message |
100+
| msg_type | U8 | Unique identifier of this protocol message |
101101
| msg_length | U24 | Length of the protocol message, not including this header |
102102
| 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. |
103103

104+
### 3.2.1 Routing Frames over Channels
105+
106+
Some bits of the `extension_type` field can also be repurposed for signaling on how the frame should be handled across channels.
107+
108+
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.
109+
110+
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`.
111+
112+
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).
113+
114+
Note that for the Job Declaration and Template Distribution Protocols the `channel_msg` bit is always unset.
104115

105116
## 3.3 Reconnecting Downstream Nodes
106117

0 commit comments

Comments
 (0)