Hi Hunje and Uze, I agree if you have some resource you want to be managed by resource hosting and some resource you want to manage on device itself, then turning multicast turning off is not a right solution.
But I am still trying to understand what will be the scenario that will require this. As per my understanding RH is will be primarily be used by devices such as thermostat to save power and they do not want to actively participate in the discovery. Non-discoverable option sounds good, but just trying to figure out what kind of scenario will this address. Kind Regards Habib From: ??? [mailto:[email protected]] Sent: 21 January 2016 10:48 To: ???; Habib Virji Cc: ???; iotivity-dev at lists.iotivity.org Subject: Re: RE: [dev] Proposal: explicit method for start of Resource Hosting Dear Habib, In my opinion, turning the multicast traffic off could cause the operational errors of other resources. it would be more clear that distinguish between the two conditions; turn the discoverable off and turn the multicast listening off; Best Regards, Hun-je. ------- Original Message ------- Sender : ???<uzchoi at samsung.com> S6(??)/??/IoT Lab(S/W??)/???? Date : 2016-01-21 19:35 (GMT+09:00) Title : RE: [dev] Proposal: explicit method for start of Resource Hosting + Jungyong.Kim If there are two resources, we can delegate the request handling for first resource into the resource hosting device, and remain the other resource discoverable in the original device. In this case, the second resource should be still discoverable. However, multicast off prohibits this scenario handling. We have a plan to add the api to change the discoverable setting into code base. Additionally we also will let the device turn off the multicast traffic for power saving if there is no remaining resource to be open. BR, Uze Choi From: Habib Virji [mailto:[email protected]] Sent: Thursday, January 21, 2016 6:29 PM To: '???(Uze Choi)' Subject: RE: [dev] Proposal: explicit method for start of Resource Hosting Hi Uze Happy New Year to you too. Hope you have a nice and prosperous year ahead. The issue with the proposal is if you do not stop multicast traffic, you will still wake up the whole stack, process the message and when non- discoverable setting is found discard the message. But with stopping multicast traffic, you do not wakeup. It should be also looked from an angle does non-discoverable flag wakeup device and does this action reduce power consumption. Also currently the flag is not used to stop discovery process, we will need to update code base to stop it. Kind Regards Habib From: ???(Uze Choi) [mailto:[email protected]] Sent: 21 January 2016 01:53 To: Habib Virji Subject: RE: [dev] Proposal: explicit method for start of Resource Hosting Habib, Happy new year, Could you check my email below? From: ???(Uze Choi) [mailto:[email protected]] Sent: Friday, January 15, 2016 11:33 AM To: Habib Virji (habib.virji at samsung.com); 'jyong2.kim at samsung.com'; '???'; 'iotivity-dev at lists.iotivity.org' Subject: RE: [dev] Proposal: explicit method for start of Resource Hosting Hi Jay, JungYoung, Dynamically setting Discoverable flag looks common use case, I think. >From the resource directory, it could be used also, which disable the multicast channel instead of undiscoverable setting. Habib, could you check the use case from your side for this new API usage from RD also? Jungyoung, you can consider the disable the multicast channel as the additional action from the ?RH delegation request device? as like current RD implementation. BR, Uze Choi From: [email protected] [mailto:iotivity-dev- bounces at lists.iotivity.org] On Behalf Of ??? Sent: Friday, January 15, 2016 8:08 AM To: ???; iotivity-dev at lists.iotivity.org Subject: Re: [dev] Proposal: explicit method for start of Resource Hosting Hello Junghyun. You are right. IoTivity Stack does not provide APIs for update resource policy. However IoTivity Stack already has functionality for update policy dynamically. (e.g. OCChangeResourceProperty() ocstack.c) So, I think if we needs to change of resource policy, we can make API easy. When review of this proposal is done, I will propose to make API for update resource policy. Regards, JungYong ------- Original Message ------- Sender : ???<junghyun.oh at samsung.com> S5(??)/??/IoT Lab(S/W??)/???? Date : 2016-01-14 18:29 (GMT+09:00) Title : RE: [dev] Proposal: explicit method for start of Resource Hosting Hi To my understanding, IoTivity Stack does not provide any APIs for updating the resource policy(such as discoverable or observable). Could provide us ?How the application could update the resource policy dynamically?? (ex Discoverable a Non-discoverable) Thank you. Jay. From: [email protected] [mailto:iotivity-dev- bounces at lists.iotivity.org] On Behalf Of ??? Sent: Thursday, January 14, 2016 5:42 PM To: iotivity-dev at lists.iotivity.org Subject: [dev] Proposal: explicit method for start of Resource Hosting Hello All. As you know, Resource Hosting(RH) already located on iotivity primitive services. RH is useful service for reduction of thin device's power consumption. But, start of RH has a problem, so I propose an explicit method for start of RH to improve it. Please check attached a proposal. As is, if thin device want to reduce power consumption, thin device can implicit requests to RH. This is very simple and easy way. But, thin device should watch for creation of hosting resource. If thin device can explicit requests, thin device should find RH, but thin device can know about creation of hosting resource. I think the latter is more clear method for start of RH. Please review and feedback this proposal. Regards, JungYong. =============================================== HUN-JE YEON (???) Senior Engineer, IoT Lab Software R&D Center Samsung Electronics Co., Ltd. Tel] +82-10-9454-4650 E-mail] <mailto:hunje.yeon at samsung.com> hunje.yeon at samsung.com =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160121/df38fb69/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 13168 bytes Desc: not available URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160121/df38fb69/attachment.gif>
