Good point about graceful/non-graceful cases. My understanding was that, the stack performed graceful closures of outstanding tasks if asked to shut down (i.e., when OCStop is called). Based on your findings, seems like that?s not the case? To me it feels like a bug in OCStop().
Better question for you: if OCStop() were to close things gracefully, will that satisfy your needs? Thanks, Way From: Morrow, Joseph L [mailto:[email protected]] Sent: Wednesday, July 5, 2017 10:02 AM To: Way Vadhanasin <Wayakorn.Vadhanasin at microsoft.com>; iotivity-dev at lists.iotivity.org Subject: Re: [dev] Suspend IoTivity Stack? Hi Way, This may not be the case. The reason I used the term ?suspend? was to illustrate the fact the IoTivity node (client or server) is gracefully leaving. It may gracefully come back. That stack itself may never actually shutdown, however. As of now, if an IoTivity node leaves the network, it can either manually call OCCancel() on each pending request it has open and deregister for any Observe/Presence updates. Then call OCStop(). I?ve found that calling to deregister for Observe/Presence notifications gets passed on to the requested peer application correctly, but the IoTivity server stack continues to try notify clients until it receives a CoAP RESET message. Although no application received any callbacks for this failed flow, this isn?t graceful since the requestor called OCCancel() and De-registered for events all together. Perhaps OCCancel() and Observe/Presence de-registration is implemented incorrectly. But, what I?m describing *could* specifically choose to shutdown any pending requests gracefully. It would ideally also be a single API. I like the idea of extending this to sessions. For example, your phone could use the same IoTivity stack both in home, office, and on the go (cloud?). Everytime your phone knows it will need to associate/un-associate with these differing places (geo-fencing?) it could gracefully suspend that session. As of now, if you don?t gracefully shutdown IoTivity and you had a pending request open, IoTivity has re-try logic in the CA layer that gets performed before the lower part of the stack determines that other node is gone. It may be negligible, but it *may* hinder performance for that moment on the node performing re-try logic. With graceful going away messages, this would go away. Thanks, Joey Morrow From: Way Vadhanasin <Wayakorn.Vadhanasin at microsoft.com<mailto:[email protected]>> Date: Monday, July 3, 2017 at 12:26 PM To: Joseph L Morrow <joseph.l.morrow at intel.com<mailto:joseph.l.morrow at intel.com>>, "iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>" <iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>> Subject: RE: [dev] Suspend IoTivity Stack? Hi Joseph, The patch I shared just deprecates OCProcess by moving the responsibility of calling OCProcess into the IoTivity stack. The goal is to idle the CPU instead of forcing apps to dedicate its main thread to call it in a loop. To answer your question: the CA layer is pretty much decoupled from the stack. It has its own receive thread that queues up the work items in the recv queue. My understanding is the recv queue is drained, one by one, each time the application calls OCProcess. When you?re talking about suspending the application, I assume you also want to stop IoTivity entirely? If my understanding is true, why can?t you just shut down the stack when you get the suspension notification? Thanks, Way From: Morrow, Joseph L [mailto:[email protected]] Sent: Saturday, July 1, 2017 1:15 PM To: Way Vadhanasin <Wayakorn.Vadhanasin at microsoft.com<mailto:Wayakorn.Vadhanasin at microsoft.com>>; iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: Re: [dev] Suspend IoTivity Stack? Hi Way, That?s great! I will look into it your changes. It looks rather large. Do you see (just a yes or no will suffice) a way to tie in hooks on this logic, such that we could implement a way to tell peers that this device is going suspend? Tell me, when you suspend OCProcess, do you also suspend CAProcess()? If so, do you stop all calls to any networking threads in the CA layer? I ask because the CA Layer is multi-threaded. Thanks, Joey Morrow From: Way Vadhanasin <Wayakorn.Vadhanasin at microsoft.com<mailto:[email protected]>> Date: Friday, June 30, 2017 at 11:17 PM To: Joseph L Morrow <joseph.l.morrow at intel.com<mailto:joseph.l.morrow at intel.com>>, "iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>" <iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>> Subject: RE: [dev] Suspend IoTivity Stack? With regards to suspending the stack, I have a patch out at https://gerrit.iotivity.org/gerrit/#/c/18277/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgerrit.iotivity.org%2Fgerrit%2F%23%2Fc%2F18277%2F&data=02%7C01%7CWayakorn.Vadhanasin%40microsoft.com%7C82b58c8520124a3b636808d4c0bdd681%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636345368966527633&sdata=palOqBa%2FAOQMiS0yNHAHO5Np4YT0qeJAmsoPJAJeBFw%3D&reserved=0> that purposes deprecating OCProcess altogether to allow app suspension. The patch was done some time ago so it needs a rebase, but it should be mostly complete. Unfortunately I had to put the work on hold for other priorities, but you?re most welcome to pick it up if you?d like. Thanks, Way From: Morrow, Joseph L<mailto:[email protected]> Sent: Friday, June 30, 2017 8:28 PM To: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: [dev] Suspend IoTivity Stack? Furthermore, I believe it may behoove us to implement a way to suspend the IoTivity stack. This should do 3 things: 1. In the C SDK, and all other higher level SDKs, it should tell the CA Layer to process all of its buffers (while returning some new ?OC_EH_SUSPENDING? to any incoming requests/responses) (I.e. call CAProcess() until no more contents in buffer) 2. In the C++ SDK and all other higher level SDKs (excluding C SDK), it should tell the C SDK to process all of its buffers (I.e. call OCProcess() one last time to process remaining buffer contents). 3. ?Perhaps? On Client side, it would unobserve and unsubscribe to any observe/presence updates before suspending. Then upon resuming, it would re-observe (and map to the app?s same onObserve callback), and similarly for Presence. This would be intended to cover cases a platform goes to deeper sleep (S3). Right now, the CA Layer monitors Network events, but not System sleep events. This would leave platform-specific sleep handling to the Application layer, but letting the IoTivity stack properly keep state and resume automatically. This would also let IoTivity peers to book-keep correctly as this platform will not be responding to incoming requests/responses, but that it will come back. Perhaps this goes back to Suspending/Resuming sessions. Think of Resuming/Suspending a session at your office vs. Resuming/Suspending a session at your home. Your cell phone IoTIvity app (of the future) should be as graceful in those networks as it can with any knowledge it may have about it coming and going away. Thanks, Joey Morrow From: Joseph L Morrow <joseph.l.morrow at intel.com<mailto:[email protected]>> Date: Friday, June 30, 2017 at 5:16 PM To: "iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>" <iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>> Subject: New Request Type: PING (Like Get, Put, Post, ...) Hi All, I was wondering if it would be a good a idea to add a Ping request type. Used primarily for development, or technician-level debugging. I?m thinking there should be a lightweight and static way to check if an IoTivity/OCF stack is up and running without doing discovery or a full CRUDN request. +1 this if you think it?s a good idea. If people like it, maybe we can get some support to add it, or discuss ideas. Let me know. Thanks, Joey Morrow -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170705/478c1d67/attachment.html>
