-
Notifications
You must be signed in to change notification settings - Fork 2.1k
sys/net/nanocoap: Implement Observe (Server-Side) #21147
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
f0a998f
to
124752f
Compare
a3e9b1c
to
c4de045
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just had a high-level look at it and have some nit's below. In general I don't feel confident enough in nanocoap_sock
to tell whether this takes all nanocoap quirks into account, but the implementation looks good to me in general.
Freeze is over so if anyone wants to pick this up... |
c4de045
to
26f4f06
Compare
Please squash! |
This allows sending a separate response with CoAP Options and adds a helper to detect duplicate requests, so that resource handlers can repeat their empty ACK on duplicates.
This adds the new `nanocoap_server_observe` module that implements the server side of the CoAP Observe option. It does require cooperation from the resource handler to work, though. Co-Authored-By: mguetschow <mikolai.guetschow@tu-dresden.de> Co-authored-by: benpicco <benpicco@googlemail.com>
88ab5fd
to
feeb684
Compare
An issue I see is that observe registrations never time out. So The server can easily fill up if clients do not unregister properly (which can easily happen when they get out of range/crash/reboot/…) Should |
We sadly cannot send fully standard compliant CONs as separate response; which we use for the notification. (In fact, there is an One could probably send the notifications as CON without doing retransmissions, breaking the standard. (I think aborting retransmissions when a more recent notification is available is probably the sane thing to do anyway, as the stated goal of the observe RFC is to get the client as closely in sync with the server state as possible; blocking a more fresh update by retransmissions of stale data is not well aligned with this.) Another approach is to just let observations time out anyway. After all, clients can in fact occasionally re-affirm their active observe registration by registering with the same token at the same resource again. This could be used to reset the timeout. |
feeb684 introduced a regression that makes the release tests fail for
(part of task 1.3)
|
Contribution description
Testing procedure
Starting the Server
Running a Client
Issues/PRs references
None