You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a protocol where packets of the same type may have different lengths and thus have different meanings.
In theory most cases could be solved by just compounding Option<T>, but that will quickly get unmanageable and won't cover cases where longer packet may have slightly different decoding of previous fields.
For example:
#[derive(Debug,Clone,PartialEq,Eq,Hash,DekuRead,DekuWrite)]structDatagramHeader{crc:u8,#[deku(bits = "1")]query:bool,#[deku(bits = "3")]_reserved:u8,/// Currently always set to 1#[deku(bits = "4")]version:u8,recipient:Address,sender:Address,sequence_number:u8,// Technically the header also has the packet type field here, but I shift it onto the enum// since different enums need to be used depending on the version field}#[derive(Debug,Clone,PartialEq,Eq,Hash,DekuRead,DekuWrite)]#[deku(id_type = "u8")]pubenumPacket{#[deku(id = "0x20")]DeviceInfo(DeviceInfo),#[deku(id = "0xF0")]Ack,}// Device info can be 0 (technically only used when query=true in header), 2 or 4 bytes #[derive(Debug,Clone,PartialEq,Eq,Hash,DekuRead,DekuWrite)]structDeviceInfo{data:Option<DeviceInfoData>,}#[derive(Debug,Clone,PartialEq,Eq,Hash,DekuRead,DekuWrite)]structDeviceInfoData{value:u16,version2_data:Option<DeviceInfoDataV2>,}#[derive(Debug,Clone,PartialEq,Eq,Hash,DekuRead,DekuWrite)]structDeviceInfoDataV2{value:u16,}
Note that the header does not contain the payload length - it is known by the virtue of knowing the total packet length (as it is given by higher layer) and the header length (as it is constant). I.e. This will always be used to decode data from pre-allocated buffers, not streams.
I suppose I could pass the payload length via context.
When deserializing the packet I first read the header then based on the fields in it (here the version field) I decode the rest accordingly (just the Packet enum for simplicity here).
BTW, any good ideas on how to update the crc field in this scenario?
For completeness I then pack this into structs and enum like this:
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
I have a protocol where packets of the same type may have different lengths and thus have different meanings.
In theory most cases could be solved by just compounding
Option<T>, but that will quickly get unmanageable and won't cover cases where longer packet may have slightly different decoding of previous fields.For example:
I would prefer to have it as such:
Note that the header does not contain the payload length - it is known by the virtue of knowing the total packet length (as it is given by higher layer) and the header length (as it is constant). I.e. This will always be used to decode data from pre-allocated buffers, not streams.
I suppose I could pass the payload length via context.
When deserializing the packet I first read the header then based on the fields in it (here the version field) I decode the rest accordingly (just the
Packetenum for simplicity here).BTW, any good ideas on how to update the
crcfield in this scenario?For completeness I then pack this into structs and enum like this:
Though for now, I do the packing/unpacking to/from the buffer of those manually.
Beta Was this translation helpful? Give feedback.
All reactions