Struct canadensis_data_types::uavcan::file::read_1_0::ReadRequest

pub struct ReadRequest {
    pub offset: u64,
    pub path: Path,
}

👎Deprecated

uavcan.file.Read.1.0

Size ranges from 6 to 118 bytes

Read file from a remote node.

There are two possible outcomes of a successful call:

1. Data array size equals its capacity. This means that the end of the file is not reached yet.
2. Data array size is less than its capacity, possibly zero. This means that the end of the file is reached.

Thus, if the client needs to fetch the entire file, it should repeatedly call this service while increasing the offset, until a non-full data array is returned.

If the object pointed by ‘path’ cannot be read (e.g. it is a directory or it does not exist), an appropriate error code will be returned, and the data array will be empty.

It is easy to see that this protocol is prone to race conditions because the remote file can be modified between read operations which might result in the client obtaining a damaged file. To combat this, application designers are recommended to adhere to the following convention. Let every file whose integrity is of interest have a hash or a digital signature, which is stored in an adjacent file under the same name suffixed with the appropriate extension according to the type of hash or digital signature used. For example, let there be file “image.bin”, integrity of which shall be ensured by the client upon downloading. Suppose that the file is hashed using SHA-256, so the appropriate file extension for the hash would be “.sha256”. Following this convention, the hash of “image.bin” would be stored in “image.bin.sha256”. After downloading the file, the client would read the hash (being small, the hash can be read in a single request) and check it against a locally computed value. Some servers may opt to generate such hash files automatically as necessary; for example, if such file is requested but it does not exist, the server would compute the necessary signature or hash (the type of hash/signature can be deduced from the requested file extension) and return it as if the file existed. Obviously, this would be impractical for very large files; in that case, hash/signature should be pre-computed and stored in a real file. If this approach is followed, implementers are advised to use only SHA-256 for hashing, in order to reduce the number of fielded incompatible implementations.

Fields

offset: u64

👎Deprecated

truncated uint40

Always aligned, size 40 bits

path: Path

👎Deprecated

uavcan.file.Path.1.0

Always aligned, size ranges from 8 to 904 bits

Trait Implementations

impl DataType for ReadRequest

const EXTENT_BYTES: Option<u32> = _

This type is delimited with an extent of 300 bytes.

impl Deserialize for ReadRequest

fn deserialize(cursor: &mut ReadCursor<'_>) -> Result<Self, DeserializeError>where Self: Sized,

Deserializes a value and returns it

fn deserialize_from_bytes(bytes: &[u8]) -> Result<Self, DeserializeError>where Self: Sized,

A convenience function that creates a cursor around the provided bytes and calls deserialize

impl Serialize for ReadRequest

fn size_bits(&self) -> usize

Returns the size of the encoded form of this value, in bits

fn serialize(&self, cursor: &mut WriteCursor<'_>)

Serializes this value into a buffer

fn serialize_to_bytes(&self, bytes: &mut [u8])

A convenience function that creates a cursor around the provided bytes and calls serialize

impl Request for ReadRequest