Note that there is a newer version https://tools.ietf.org/html/draft-li-core-conditional-observe-05 that uses different options and provides less features. The draft is also ?personal,? i.e., not supported by the working group yet. The reason for the feature roll-back from version 02 to 05 were conflicts with other standards and unnecessary mechanisms, as far as I know (we could ask one of the authors). https://tools.ietf.org/html/draft-ietf-core-interfaces-02 would be the preferred way in this case (the pmin, pmax, and st attributes are also compatible with OMA LWM2M). Best regards Matthias
From: ???(Uze Choi) [mailto:uzc...@samsung.com] Sent: Freitag, 17. April 2015 17:11 To: junghyun.oh at samsung.com; 'Samidurai, Sakthivel'; 'Kesavan, Vijay S'; 'Lankswert, Patrick'; Kovatsch Matthias; ??? Cc: iotivity-dev at lists.iotivity.org Subject: RE: Re: RE: Re: Re: [dev] [Multicast presence Issue raise] FW: Inquire about base C API for multicast presence There is already draft for this in Conditional observe in CoAP. https://tools.ietf.org/html/draft-li-core-conditional-observe-02 How about to implement it into the IoTivity. This will enable various usecases. BR, Uze Choi From: Jung-Hyun Oh [mailto:junghyun...@samsung.com] Sent: Friday, April 17, 2015 3:54 PM To: Jung-Hyun Oh; Samidurai, Sakthivel; Kesavan, Vijay S; ???; Lankswert, Patrick; kovatsch at inf.ethz.ch Cc: iotivity-dev at lists.iotivity.org Subject: Fwd: Re: RE: Re: Re: [dev] [Multicast presence Issue raise] FW: Inquire about base C API for multicast presence (+) Matthias ------- Original Message ------- Sender : Jung-Hyun Oh<junghyun.oh at samsung.com<mailto:junghyun.oh at samsung.com>> S5/Senior Engineer/IoT Solution Lab./Samsung Electronics Date : 2015-04-17 15:35 (GMT+09:00) Title : Re: RE: Re: Re: [dev] [Multicast presence Issue raise] FW: Inquire about base C API for multicast presence Sam, Thanks for your reply. :) Pat, One & last question for the presence feature. Is it okey to think that If I call the "StartPresence" with ttl value from the Application, then the C-Stack will automatically(or periodically) check the ttl & status-change of the stack itself in order to multicast the presence packet to those observers (unicast presence subscribers)? Since you people are busy for preparing the release, I do not want to interrupt you on this so if there's any doc. explains about this, then it's okey to share instead. Thanks in advance. Jay. ------- Original Message ------- Sender : Samidurai, Sakthivel<sakthivel.samidurai at intel.com<mailto:sakthivel.samidurai at intel.com>> Date : 2015-04-17 11:22 (GMT+09:00) Title : RE: Re: Re: [dev] [Multicast presence Issue raise] FW: Inquire about base C API for multicast presence Jay, Pat explained TTL in the attached email. Please let us know if you need more information. Thanks, =Sam From: ??? [mailto:junghyun...@samsung.com] Sent: Thursday, April 16, 2015 5:26 PM To: ???; Samidurai, Sakthivel; Kesavan, Vijay S; ??? Cc: iotivity-dev at lists.iotivity.org Subject: Fwd: Re: Re: [dev] [Multicast presence Issue raise] FW: Inquire about base C API for multicast presence Sam, One more thing. :) Could explain us the "Subject" or "Purpose" of the ttl for the API "OCStartPresence()"? Let me clarify my question with the definition of "ttl" & please correct me if I'm wrong. TTL : Maximum time for multicasting the presence packet from Resource server side. Q1. The presene packet can only be sent when the Application calls the "OCProcess". Sample applications are using "While loop" in order to call the "OCProcess" to multicast the presence packet. Then what is the usage the the "TTL" if the C-Stack doesn't care this TTL. inside? The doxygen description in the header is not enough for us to understand the usage of it. So we will be appreciated if you share us bit more detailed information of Presence feature related APIs. Thank you. Jay. ------- Original Message ------- Sender : ???<junghyun.oh at samsung.com<mailto:junghyun.oh at samsung.com>> S5(??)/??/IoT Solution Lab(S/W??)/???? Date : 2015-04-17 09:12 (GMT+09:00) Title : Re: Re: [dev] [Multicast presence Issue raise] FW: Inquire about base C API for multicast presence Hi Sam, I have a question based on your reply.. Why the format of input parameter for the "Presence Check" is different? Since the multicast presence need uri without scheme & port #, unicast presence requires fully uri (scheme://address:port/path). Could we abstract the input parameter for the presence bit more general form? ex) Remove, scheme(coap, http, etc..), the Multicast IP Addr(224.0.1.187) & Common Uri(/oc/presence) Anyway, I will talk with developers who reported this issues with your answer. Thank you. Jay. ------- Original Message ------- Sender : Samidurai, Sakthivel<sakthivel.samidurai at intel.com<mailto:sakthivel.samidurai at intel.com>> Date : 2015-04-17 08:10 (GMT+09:00) Title : Re: [dev] [Multicast presence Issue raise] FW: Inquire about base C API for multicast presence Uze, We are unable to reproduce the presence issue. We tested on the same and two systems with WI-FI/Ethernet. We tested with both C++ and C sample and clients is getting the presence notification. ? Multicast presence: The app can use ?224.0.1.187/oc/presence? ? Unicast Presence: The app can use ?coap://<server IP>:6298/oc/presence? We recommend trying the Iotivity base C/C++ sample application on your test system and let us know the test results. Please open a JIRA ticket and provide steps to reproduce the issue. The client does not receive any presence notification if the client discovered the server but there is no change in the resource. In this case, the server does not send any presence notification. Please note that we identified a presence TIMEOUT issue that is not related to the presence issue that you have reported. The presence timeout fix is in the changeset https://gerrit.iotivity.org/gerrit/#/c/759/ with commit ad60f765b797923ca457322abb83331c9563e12f. The misleading presence log messages in C sample server source (ocserver.cpp) are modified in the changeset : https://gerrit.iotivity.org/gerrit/#/c/748/ The test log is below for your reference. Multicast presence Log: query: 224.0.1.187/oc/presence<http://224.0.1.187/oc/presence> requiredUri=224.0.1.187/oc/presence<http://224.0.1.187/oc/presence> referenceUri=(null) conType=1 43:21.738 INFO: occlient: Callback Context for Presence recvd successfully 43:21.738 INFO: occlient: StackResult: OC_STACK_OK 43:21.738 INFO: occlient: NONCE NUMBER: 154451112 43:21.738 INFO: occlient: Callback Context for Presence notification recvd successfully 0 43:21.738 INFO: occlient: JSON = (null) =============> Presence Response 43:23.738 INFO: occlient: Callback Context for Presence recvd successfully 43:23.738 INFO: occlient: StackResult: OC_STACK_OK 43:23.738 INFO: occlient: NONCE NUMBER: 4221900748 43:23.738 INFO: occlient: Callback Context for Presence notification recvd successfully 1 43:23.738 INFO: occlient: JSON = (null) =============> Presence Response 43:27.738 INFO: occlient: Callback Context for Presence recvd successfully 43:27.738 INFO: occlient: StackResult: OC_STACK_OK 43:27.738 INFO: occlient: NONCE NUMBER: 2132196551<tel:2132196551> 43:27.738 INFO: occlient: Callback Context for Presence notification recvd successfully 2 43:27.738 INFO: occlient: JSON = (null) =============> Presence Response 43:29.738 INFO: occlient: Callback Context for Presence recvd successfully 43:29.738 INFO: occlient: StackResult: OC_STACK_OK 43:29.738 INFO: occlient: NONCE NUMBER: 2474188232 43:29.738 INFO: occlient: Callback Context for Presence notification recvd successfully 3 43:29.738 INFO: occlient: JSON = (null) =============> Presence Response Unicast presence Log: Query: coap://192.168.1.104:6298/oc/presence<http://192.168.1.104:6298/oc/presence> 46:48.042 INFO: occlient: Callback Context for Presence recvd successfully 46:48.042 INFO: occlient: StackResult: OC_STACK_OK 46:48.042 INFO: occlient: NONCE NUMBER: 98872639 46:48.042 INFO: occlient: Callback Context for Presence notification recvd successfully 0 46:48.042 INFO: occlient: JSON = (null) =============> Presence Response 46:52.042 INFO: occlient: Callback Context for Presence recvd successfully 46:52.042 INFO: occlient: StackResult: OC_STACK_OK 46:52.042 INFO: occlient: NONCE NUMBER: 3881206201 46:52.042 INFO: occlient: Callback Context for Presence notification recvd successfully 1 46:52.042 INFO: occlient: JSON = (null) =============> Presence Response 46:54.042 INFO: occlient: Callback Context for Presence recvd successfully 46:54.042 INFO: occlient: StackResult: OC_STACK_OK 46:54.042 INFO: occlient: NONCE NUMBER: 2187039498<tel:2187039498> 46:54.042 INFO: occlient: Callback Context for Presence notification recvd successfully 2 46:54.042 INFO: occlient: JSON = (null) =============> Presence Response 46:56.042 INFO: occlient: Callback Context for Presence recvd successfully 46:56.042 INFO: occlient: StackResult: OC_STACK_OK 46:56.042 INFO: occlient: NONCE NUMBER: 474262046 46:56.042 INFO: occlient: Callback Context for Presence notification recvd successfully 3 46:56.042 INFO: occlient: JSON = (null) =============> Presence Response We have highlighted the presence notification being sent by the server and them being received by the client. linux/SimpleClientServer$ ./ocserver -o0 29:50.982 DEBUG: ocserver: OCServer is starting... Sending presence notification Sending presence notification Sending payload 1983849130:60 Sending presence notification Sending payload 876748912:60:core.light 29:50.990 INFO: ocserver: Created Light resource with result: OC_STACK_OK 29:50.990 INFO: ocserver: Entering ocserver main loop... Sending payload {"href":"/a/light","sid":"2441775918","prop":{"rt":["core.light"], "if":["oc.mi.def"],"obs":1}} Sending presence notification Sending payload 876748912:60 30:00.998 INFO: ocserver: ================ presence count 10 30:00.998 INFO: ocserver: Creating /a/fan for presence Sending presence notification Sending payload 285258306:60:core.fan 30:06.002 INFO: ocserver: Creating /a/led for presence Sending presence notification Sending payload 1003359691:60:core.led 30:11.002 INFO: ocserver: ================ presence count 9 30:16.003 INFO: ocserver: Deleting /a/fan for presence Sending presence notification Sending payload 126341009:60:core.fan 30:21.003 INFO: ocserver: ================ presence count 8 30:21.003 INFO: ocserver: Deleting /a/led for presence Sending presence notification Sending payload 4292822242:60:core.led 30:31.003 INFO: ocserver: ================ presence count 7 30:41.003 INFO: ocserver: ================ presence count 6 30:51.003 INFO: ocserver: ================ presence count 5 31:01.003 INFO: ocserver: ================ presence count 4 31:11.003 INFO: ocserver: ================ presence count 3 31:21.003 INFO: ocserver: ================ presence count 2 31:31.003 INFO: ocserver: ================ presence count 1 31:41.003 INFO: ocserver: ================ stopping presence Sending payload 558822771:0 ./occlient -c1 -t12 29:52.350 INFO: occlient: Entering occlient main loop... 29:58.350 INFO: occlient: Callback Context for DISCOVER query recvd successfully 29:58.350 INFO: occlient: StackResult: OC_STACK_OK 29:58.350 INFO: occlient: Discovered on WiFi 29:58.350 INFO: occlient: Device =============> Discovered {"oc":[{"href":"/a/light","sid":"2441775918","prop":{"rt":["core.light"], "if":["oc.mi.def"],"obs":1}}]} @ 10.246.31.157:6298 29:58.350 INFO: occlient: Executing InitPresence 30:00.354 INFO: occlient: Callback Context for Presence recvd successfully 30:00.354 INFO: occlient: StackResult: OC_STACK_OK 30:00.354 INFO: occlient: NONCE NUMBER: 876748912 30:00.354 INFO: occlient: Callback Context for Presence notification recvd successfully 0 30:00.354 INFO: occlient: JSON = (null) =============> Presence Response 30:02.354 INFO: occlient: Callback Context for Presence recvd successfully 30:02.354 INFO: occlient: StackResult: OC_STACK_OK 30:02.354 INFO: occlient: NONCE NUMBER: 285258306 30:02.354 INFO: occlient: Callback Context for Presence notification recvd successfully 1 30:02.354 INFO: occlient: JSON = (null) =============> Presence Response 30:06.358 INFO: occlient: Callback Context for Presence recvd successfully 30:06.358 INFO: occlient: StackResult: OC_STACK_OK 30:06.358 INFO: occlient: NONCE NUMBER: 1003359691 30:06.358 INFO: occlient: Callback Context for Presence notification recvd successfully 2 30:06.358 INFO: occlient: JSON = (null) =============> Presence Response 30:16.379 INFO: occlient: Callback Context for Presence recvd successfully 30:16.379 INFO: occlient: StackResult: OC_STACK_OK 30:16.379 INFO: occlient: NONCE NUMBER: 126341009 30:16.379 INFO: occlient: Callback Context for Presence notification recvd successfully 3 30:16.379 INFO: occlient: JSON = (null) =============> Presence Response 30:22.387 INFO: occlient: Callback Context for Presence recvd successfully 30:22.387 INFO: occlient: StackResult: OC_STACK_OK 30:22.387 INFO: occlient: NONCE NUMBER: 4292822242 30:22.387 INFO: occlient: Callback Context for Presence notification recvd successfully 4 30:22.387 INFO: occlient: JSON = (null) =============> Presence Response 31:22.447 INFO: occlient: Callback Context for Presence recvd successfully 31:22.447 INFO: occlient: StackResult: OC_STACK_PRESENCE_TIMEOUT 31:22.447 INFO: occlient: NONCE NUMBER: 0 31:22.447 INFO: occlient: Callback Context for Presence notification recvd successfully 5 31:22.447 INFO: occlient: JSON = (null) =============> Presence Response 31:42.455 INFO: occlient: Callback Context for Presence recvd successfully 31:42.455 INFO: occlient: StackResult: OC_STACK_PRESENCE_STOPPED 31:42.455 INFO: occlient: NONCE NUMBER: 558822771 31:42.455 INFO: occlient: Callback Context for Presence notification recvd successfully 6 31:42.455 INFO: occlient: JSON = (null) =============> Presence Response Thanks, =Sam From: iotivity-dev-bounces at lists.iotivity.org<mailto:iotivity-dev-bounces at lists.iotivity.org> [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Kesavan, Vijay S Sent: Wednesday, April 15, 2015 6:21 PM To: uzchoi at samsung.com<mailto:uzchoi at samsung.com> Cc: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: Re: [dev] [Multicast presence Issue raise] FW: Inquire about base C API for multicast presence Uze, The team is investigating both the presence issues. We do not have a fix yet and will provide either a fix or an update to you by tomorrow. It sounded like Jyong Kim?s suggestion is addressing the multicast presence issue for you, so we are prioritizing the unicast presence issue. In any case, we will send you an update tomorrow. --Vijay From: ???(Uze Choi) [mailto:uzc...@samsung.com] Sent: Wednesday, April 15, 2015 6:09 PM To: Kesavan, Vijay S Cc: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: RE: [Multicast presence Issue raise] FW: [dev] Inquire about base C API for multicast presence Hi Vijay, Would you mind answering for my question? Your answer will affect our QA test schedule, so that we need it. BR, Uze Choi From: ???(Uze Choi) [mailto:uzc...@samsung.com] Sent: Wednesday, April 15, 2015 7:30 PM To: Kesavan, Vijay S (vijay.s.kesavan at intel.com<mailto:vijay.s.kesavan at intel.com>) Cc: 'iotivity-dev at lists.iotivity.org' Subject: [Multicast presence Issue raise] FW: [dev] Inquire about base C API for multicast presence Importance: High Hi Vijay, We are urgently integrating the master branch merged from CA with our primitive services. There seems to be several major problems but I wish you resolve two issues regarding multicast presence. 1. Multicast presence issue in the C API layer as following mail.(Doil.Kwon) 2. Unicast Presence request fail (Hyunjun.Kim will send detail later) If you willing to fix them in a couple of days, we will wait. Unless we will fix our code workaround which may cause the side effect, but there is no other option to make the release time. If possible let us know the status on tomorrow OSWG CC. or direct call setup please. BR, Uze Choi From: iotivity-dev-bounces at lists.iotivity.org<mailto:iotivity-dev-bounces at lists.iotivity.org> [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ??? Sent: Wednesday, April 15, 2015 10:54 AM To: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: [dev] Inquire about base C API for multicast presence Dear iotivity-dev members. i am doil kwon and resource hosting developer. our application is not working about multicast presence for using base C API. After analyzing causes, previous version is a request for using uri that is "coap://224.0.1.187/oc/presence" in order to request multicast presence, After merging "CA branch",we didn't receive callback message about presence although we request,too. so, Checking "Base" and "CA" code, if there is not port, don't transfer message(ex: "coap://224.0.1.187/oc/presence"), and if there is port, can transfer message(ex: "coap://224.0.1.187:5683/oc/presence"),but don't find cbData when receiving callback message. it is occurred that we don't find cbData because occlientcb search for multicast presence request uri using "224.0.1.187/oc/presence". so, i want to know how we can solve this problem. if you know this, plz tell me about any solution. BR, doil kwon. ________________________________ ? ? ? (Doil Kwon) S3 / Assistant Engineer Advanced Convergence Lab. Software R&D Center. Samsung Electronics Co., Ltd. Tel: +82-31-279-3894 Mobile : +82-10-5648-2660 E-Mail : doil.kwon at samsung.com<mailto:doil.kwon at samsung.com> ________________________________ Jung-hyun Oh. IoT Solution Lab. | SW R&D Center | SAMSUNG ELECTRONICS CO.,LTD Mobile +82-10-9890-6731 | Beyond your imagination, Always Jung-hyun Oh. IoT Solution Lab. | SW R&D Center | SAMSUNG ELECTRONICS CO.,LTD Mobile +82-10-9890-6731 | Beyond your imagination, Always [Image removed by sender.] -------Original Message-------- Sent: "Lankswert, Patrick" <patrick.lankswert at intel.com<mailto:patrick.lankswert at intel.com>> Date: Thu, 16 Apr 2015 16:23:04 +0000 Subject: Re: [dev] Question - What is the usage of the "ttl" when using the "OCStartPresence" Jay, The TTL determines how long a device can be off the network before the stack considers it ?gone?. So, a long TTL (for example, 4 hours) means that you will not be notified that the device is offline until it is not seen for 4 hours. So, a short TTL (for example, 10 seconds) means that you will be notified very quickly if the device goes offline. You may even get some false positives (ie. it looks down when it really is not.) The tradeoff is network traffic. The shorter the TTL the more messages are sent over the wire to maintain presence. The decision on the TTL is application specific since the device designer needs to trade-off timeliness against batter power, etc. I would recommend starting with a TTL of 60 seconds. Does this help? BTW, as you may have heard this API needs to be refactored for simplicity and clarity. Once the community has a proposal, I hope that as a user of the API you will be available for commenting. Pat From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ??? Sent: Thursday, April 16, 2015 5:50 AM To: iotivity-dev at lists.iotivity.org Subject: [dev] Question - What is the usage of the "ttl" when using the "OCStartPresence" Hi Pat, I have a question about one API in the ocstack which is "OCStartPresence" That API receives the "ttl" which probablity means "time to live". Question is "what is the subject of the time-to-live? and "what is the purpose of setting the time-to-live?" I just want to use this API as intended. :) Thank you. Jay. Jung-hyun Oh. IoT Solution Lab. | SW R&D Center | SAMSUNG ELECTRONICS CO.,LTD Mobile +82-10-9890-6731 | Beyond your imagination, Always [Image removed by sender. http://ext.samsung.net/mailcheck/SeenTimeChecker?do=d083a0c0528fae52b1a7ecd7ee82214a4503773a2bde9bd6ed81201521b94ff84e60fcf6aeb61df594c3b6ddffd7613bcb238d00164b0be48eeb9bec5ad9c75d326bbdfb2ea96a2fcf878f9a26ce15a0] Jung-hyun Oh. IoT Solution Lab. | SW R&D Center | SAMSUNG ELECTRONICS CO.,LTD Mobile +82-10-9890-6731 | Beyond your imagination, Always Jung-hyun Oh. IoT Solution Lab. | SW R&D Center | SAMSUNG ELECTRONICS CO.,LTD Mobile +82-10-9890-6731 | Beyond your imagination, Always -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150417/dc830c95/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ~WRD388.jpg Type: image/jpeg Size: 823 bytes Desc: ~WRD388.jpg URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150417/dc830c95/attachment.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 344 bytes Desc: image001.jpg URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150417/dc830c95/attachment-0001.jpg>
