On 7/5/17, 12:41 PM, "Macieira, Thiago" <thiago.macieira at intel.com> wrote:

>On quarta-feira, 5 de julho de 2017 10:15:28 PDT Morrow, Joseph L wrote:
>>    This has the potential to sound fine and dandy for servers. I don?t think 
>> I
>>    can say the same for clients. Clients should be allowed to come and go as
>>    they please. And with that, they should be allowed to come and go
>>    gracefully.
>
>  That's true. I was mostly thinking about servers and they (today) have to be 
>  always-on. Clients don't have that requirement.
>
>  But clients also could sleep any time that they wanted to. It's up to the 
>  application layer to decide that. If it has no reply outstanding to a 
> request 
>  it's recently sent, it can sleep. Worst case scenario is that it will miss 
>  some notification updates, if it subscribed to anything. In fact, a good 
> client 
>  should cancel any notifications it may have and when it resumes, it re-syncs.

[JLM] Currently, observe fails ungracefully and is removed from list of 
observers in the stack. The application layer has no control over it. Also if 
HighQOS is enabled, the CA layer appears to spend some cycles to re-try. I 
agree, a good client should cancel any notifications it may have when it goes 
to sleep. But this could also be added as an easy-to-use API to further 
encourage this graceful behavior. 

> 
>>    Is this a case you can even build a certification test for? I suppose you
>>    could suspend a client and have the CTT tool look for the appropriate
>>    messages and come back into the session and continue the CTT battery of
>>    tests. That would have the same level of user interaction required during
>>    testing as tests for NOTIFY currently require.
>
>  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.

Thanks,

Joey Morrow
>

Reply via email to