-
Notifications
You must be signed in to change notification settings - Fork 134
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
3 changed files
with
96 additions
and
59 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,25 +1,31 @@ | ||
//! The SV2 protocol is binary, with fixed message framing. | ||
//! Each message begins with the extension type, message type, and message length (six bytes in total), followed by a variable length message. | ||
//! | ||
//! This crate provides primitives for framing of SV2 binary messages. | ||
//! | ||
//! The message framing is outlined below: | ||
//! | ||
//! | Protocol Type | Byte Length | Description | | ||
//! |----------------|-------------|-------------| | ||
//! | `extension_type` | `U16` | Unique identifier of the extension describing this protocol message. <br><br> Most 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><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><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><br> Note that for the Job Declaration and Template Distribution Protocols the `channel_msg` bit is always unset. | | ||
//! | `msg_type` | `U8` | Unique identifier of the extension describing this protocol message. | | ||
//! | `msg_length` | `U24` | Length of the protocol message, not including this header. | | ||
//! | `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`. | | ||
//! | ||
//! # Features | ||
//! This crate can be built with the following features: | ||
//! - `with_serde`: builds `binary_sv2` and `buffer_sv2` crates with `serde`-based encoding and decoding. | ||
//! - `with_buffer_pool`: uses `buffer_sv2` to provide a more efficient allocation method for `non_std` environments. Please refer to `buffer_sv2` crate docs for more context. | ||
#![no_std] | ||
extern crate alloc; | ||
|
||
/// | ||
/// Sv2 messages are framed as | ||
/// ```txt | ||
/// extension type: u16 | ||
/// msg type: u8 | ||
/// msg length: u24 | ||
/// payload: [u8; msg length] | ||
/// ``` | ||
/// | ||
/// Sv2 messages can be encapsulated in noise messages, noise messages are framed as: | ||
/// | ||
/// ```txt | ||
/// msg length: u16 | ||
/// payload: [u8; msg length] | ||
/// ``` | ||
/// | ||
/// | ||
/// SV2 framing types | ||
pub mod framing2; | ||
|
||
/// SV2 framing errors | ||
pub mod error; | ||
|
||
/// SV2 framing header | ||
pub mod header; | ||
pub use error::Error; |