toad_msg/msg/ty.rs
1use super::MessageParseError;
2
3/// Indicates if this message is of
4/// type Confirmable (0), Non-confirmable (1), Acknowledgement (2), or Reset (3).
5///
6/// See [RFC7252 - Message Details](https://datatracker.ietf.org/doc/html/rfc7252#section-3) for context
7#[derive(Copy, Clone, Hash, Eq, Ord, PartialEq, PartialOrd, Debug)]
8pub enum Type {
9 /// Some messages do not require an acknowledgement. This is
10 /// particularly true for messages that are repeated regularly for
11 /// application requirements, such as repeated readings from a sensor.
12 Non,
13 /// Some messages require an acknowledgement. These messages are
14 /// called "Confirmable". When no packets are lost, each Confirmable
15 /// message elicits exactly one return message of type Acknowledgement
16 /// or type Reset.
17 Con,
18 /// An Acknowledgement message acknowledges that a specific
19 /// Confirmable message arrived. By itself, an Acknowledgement
20 /// message does not indicate success or failure of any request
21 /// encapsulated in the Confirmable message, but the Acknowledgement
22 /// message may also carry a Piggybacked Response.
23 Ack,
24 /// A Reset message indicates that a specific message (Confirmable or
25 /// Non-confirmable) was received, but some context is missing to
26 /// properly process it. This condition is usually caused when the
27 /// receiving node has rebooted and has forgotten some state that
28 /// would be required to interpret the message. Provoking a Reset
29 /// message (e.g., by sending an Empty Confirmable message) is also
30 /// useful as an inexpensive check of the liveness of an endpoint
31 /// ("CoAP ping").
32 Reset,
33}
34
35impl TryFrom<u8> for Type {
36 type Error = MessageParseError;
37
38 fn try_from(b: u8) -> Result<Self, Self::Error> {
39 match b {
40 | 0 => Ok(Type::Con),
41 | 1 => Ok(Type::Non),
42 | 2 => Ok(Type::Ack),
43 | 3 => Ok(Type::Reset),
44 | _ => Err(MessageParseError::InvalidType(b)),
45 }
46 }
47}