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
