This is where I reach into my pocket and bring out the idea of sessions once more. You could unload/pre-load session info. I use the term session as some IoTivity client actively connected to some smart office or smart home. Each smart space would be its own session. I would want my smart phone to recognize I?m no longer in the office, but I?m at home and want to the control the thermostat in my home instead. As a user, I don?t want to restart my app or click some button to re-perform discovery for this to work. As a developer, I don?t want to do this session control myself if IoTivity has all the book-keeping available already. It?s redundant as long as IoTivity were to expose some OCSuspendSession()/OCActivateSession() set of APIs. Then the app developer only needs to know he/she needs to call those APIs based on some events (Geo Fence trigger, or bluetooth connected devices).
Thanks, Joey Morrow On 7/5/17, 12:59 PM, "Macieira, Thiago" <thiago.macieira at intel.com> wrote: >On quarta-feira, 5 de julho de 2017 12:53:52 PDT Morrow, Joseph L wrote: >> > I don't think you could write a certification case for this. The CTT can't >> > tell the entire device sleeping from the application deciding to do >> > nothing. >> [JLM] The client device itself doesn?t have to sleep. The IoTivity stack has >> to simply send a ?suspend? message and do proper book-keeping such that it >> de-registers appropriately. The server also needs to heed this message. In >> the case of CTT, the client will need to send a ?suspend? message, then the >> client shouldn?t respond to further OCF requests/responses whether they >> were pending or not. > >My point is that it shouldn't have to send any messages. The following >situations should be externally indistinguishable: > * doing nothing > * IoTivity stack suspending operations > * process being SIGSTOP'ped > * process exiting, crashing or being killed > * device rebooting and coming back > * device powering down > >The only distinction would be if there's a server that sends this device a >notification update. The sender may receive back an ICMP port-unreachable >error >message if the process died or the device rebooted. And since we're not >dedicating sockets per client, it's unlikely that IoTivity CA is getting that >ICMP error back from the OS. > >Or are our notify updates sent as CoAP CON? If they are confirmed, the lack of >notification in all but the first case would qualify as endpoint dead. > >-- >Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center >
