-
Notifications
You must be signed in to change notification settings - Fork 2k
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
gcoap: Observe extension server #6469
Conversation
FYI: I just merged your gcoap/observe branch. Thanks! |
Thanks for merging, and for the refactor of the uint parse code! I updated my nanocoap pkg to use your repository again. |
After reviewing the nanocoap update and thinking about the rest of Observe, it seemed time for the kind of reassurance unit tests can bring. So, now we have sock PR #11! Back to Observe itself now. |
Added generation of Observe notifications. The implementation follows the outline in the first posting for this PR. See the new "Observe Server" section in the source documentation to give it a try. The most recent commit shows how I added Observe support for the CLI example. It's a one-liner! It took a while to figure out how to generate the option value (serial number) for the notification. I like the outcome -- simple and stateless, and allows the user to minimize the length of the option. I think client deregistration is all that's left for this PR. I think it would be simpler to implement the client side of Observe in a separate PR, so I renamed this PR to be more specific. But even before I work on the client side, I need to add Confirmable messaging to make the server side compliant. Sec. 4.5 says a notification must be sent confirmably at least once a day to be sure the client still exists. |
Updated yesterday's commits to fix static test failures. |
Added Observe deregistration. I plan to automate the functional tests, rebase and squash, and then should be ready to remove the WIP label. |
Code complete, squashed. Ready for review. I removed 'WIP' from the title; please remove the label as well. Merge for this PR is blocked on merge for #6243. @kaspar030, I'd be grateful if you would review that one first. As described there, I updated the unit tests to show that it works. |
I am reconsidering this PR's readiness for merge. My concern is the implementation of Next, I plan to work through the alternative implementation to be sure it works better. Of course, any comments are welcome. |
Finished with rework. Ready for review. Removed The new approach provides for more control over messaging and data buffering. The value of this approach should become clearer with the implementation of confirmable messaging, which I plan to work on soon. |
Created a test application to send notifications from a thread running on the native platform, the observe GET model seems to work brilliantly. Copper uses by default the lazy subscribe and cancels the notification via a reset message. This results in a 4.04 returned by RIOT and not canceling the subscription. Should this approach work for non-confirmable messages? |
Thanks for the report on using Observe, @KBraham! No, the lazy/reset mechanism is not supported. Presently the implementation relies on receipt of an explicit cancellation GET with the Observe option value of 1. I leaned on the Implementation Note at the end of Sec. 4.5 in the RFC which says the lazy/reset mechanism isn't required for non-confirmable notifications. On the other hand, it's pretty uncool to respond to a RST message, but gcoap does not process them yet. :-/ Handling CON/ACK/RST is the next significant feature I plan to add. See the status page for the roadmap. I definitely will add a note to the source documentation on how to cancel an Observe session. I also will play more with Copper. It will be good to verify against another implementation besides libcoap. |
Is this still WIP ? Would be great to have it in 2017.04. |
@aabadie, thanks for checking in. This PR is no longer WIP. The last commit needs to be squashed in, but I thought I would wait for review first. Also, it's not clear why the latest build failed. Please try running that again to confirm. This PR depends on #6243, which should be straightforward. Also, #6786 reduces memory use for gcoap, and I would appreciate review for that one, too. |
I would like to add another remark on the observe implementation, it seems clients which simultaneously subscribe a resource will only allow one to reserve an observe registration. I was expecting that multiple clients (in this case originating from the same source machine) should register multiple active sessions. I have traced this using the debug prints to "gcoap: can't register observer" which fails on the resource_memo == NULL check as a memo is registered for the coap resource by the first client. Is each resource only observable by one client at most when using concurrency? They do provide different tokens for the session and thus should be separate entries? After releasing the session another client can claim the resource to observe. |
Thanks again for your feedback! Yes, there is a limitation of one observer per resource. I did actually document this one under "Observe Server Operation" in the module docs. I view this limitation as tentative -- maybe it should be removed in the future, but I wanted to be conservative for these reasons:
As you can see on the Memory Use page, I have been measuring lately. Observe already adds 800 B of text. If there needs to be multiple clients per resource, maybe that should be handled by a single, more capable client. This tension between features and memory use makes me crazy at times. It really depends on use cases, and I couldn't justify this one, at least right now. So, I'd be very interested to know what you're trying to accomplish with this scenario. |
Ok, let me know when you are done. I'll be quite busy before 11th of may so I probably won't find time for testing before. |
Fixed a logic error to ensure an observer record is allocated only if a memo record is allocated. The diff looks extensive, but mostly I just reordered the steps. You can see the added test, 'reg-cleanup', in commit 0336aa8 of my gcoap-test project. |
Also fixed a logic error (3a9582b) to ensure the observe memo lookup matches the requested endpoint. Did not add a test because the error would occur in a situation that is difficult to create -- when the tokens match for the endpoints. @aabadie, done with fixes. I'm happy to respond to any further questions or concerns. |
Created a temperature collection app to exercise gcoap and Observe. Nothing like an example to help others get started. :-) |
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.
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.
Didn't find time for testing but if @haukepetersen is happy, so am I.
:-) |
Can the WIP label be removed then? |
IMHO yes. I'd say we merge this in the current state and enhance/fix as we go. This will simplify and speed up things, right? |
Glad to hear Observe worked for you @haukepetersen, and thanks to all for moving this forward. Will squash and rebase ASAP. |
Squashed and rebased. My functional tests pass on native and samr21-xpro. |
I can confirm. Murdock is happy, ACKs are there -> let's go! @kb2ma thanks for the great work, looking forward to support for |
@kb2ma great! |
Milestone logged on the status page! |
I don't see why the CI let this PR pass. I'm getting build errors on current
|
Sorry for the noise, got the compilation working again after |
Observe (RFC 7641) provides a push mechanism for a CoAP server to notify clients of changes to a resource. Elimination of polling for this data is valuable in a constrained environment.
Initial work in this PR is on the server side. Presently the implementation is able to accept a client's registration for a resource, and then include an Observe option in the response. No ongoing notifications yet. Depends on PR #6243.
The PR uses my fork of @kaspar030's sock repository to add common data and utility code for Observe. This work then can be used for an Observe implementation for nanocoap. Of course, I'll work to get these additions upstream.
I see a clear path to implementation of ongoing notifications. This mechanism will work in two phases:
Once I have implemented notifications, the PR should be useful. I'll refresh when it's ready.