martindisch
commented
2 weeks ago That's a good suggestion, however it's not as simple as making confirmation optional on a per-observer basis. After all we might still want to send some confirmable messages to the observer. For example, the RFC says on page 18 that even when doing mostly non-confirmable messages, a server must still occasionally send notifications as confirmable to find out if the client is still there.
To allow both behaviors, I propose altering your idea such that you can now tell Subject.resource_changed whether you sent the message as confirmable or not, and it will only increase the counter of unacknowledged messages if appropriate.
Please test if the implementation from the linked PR works for you and consider if it makes sense.
According to the CoAP Observe Option RFC 7641, there is no restriction whether a notification (get observe's response) should be MessageType::confirmable or MessageType::NonConfirmable. It says (in page 6) that "The server may send a notification in a confirmable CoAP message to request an acknowledgement from the client." and not MUST (as the RFC's standard for limitations) send.
However, in the observe.rs implementation, the existence of 'unacknowledged_messages' member in 'struct Observer' as 'u8' (and 'unacknowledged_limit' of Subject) practically selects a side and restricts the library user to only receive support for confirmable notifications. If we add the implementation of Subject::resource_changed, specifically the "retain" of every observer that reach the ack limit, we will find that the library don't support the non-confirmable option.
A use case for the non-confirmable side is obvious - say we need to minimize the transferred data (hence - also the number of coap protocol's packets) between client and server that communicates over a reliable connection (which eliminates the need of Acknowledgments). It is directly implied that with the current library support, for each notification, we will be "fined" with an additional (and unnecessary) ack message.
The solution is pretty trivial: We can change the Observer::unacknowledged_messages member to be Option (instead of u8). That will allow the user to choose between confirmable or non-confirmable notification for every resource's observer it registers.
Another minor change that should be done is in the 'create_notification' function that currently set the message type to be 'MessageType::Confirmable'.
Thanks in advance for your support.