Hun-je, After thinking about your issue, I realize it is reasonable to supply default behavior in your case. In the IPv6 adapter patch (coming soon!), if the adapter type is zero, we will assume you want the IP adapter.
* This is consistent with behavior before the addition of additional adapters. * IP (and IPv6) will likely be the predominant transport by a large margin. I?m sorry I didn?t realize this in time to save you this difficulty. John Light From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Light, John J Sent: Monday, July 06, 2015 8:06 AM To: hunje.yeon at samsung.com; iotivity-dev at lists.iotivity.org Subject: Re: [dev] presence is not working Hun-je, With the addition of RI support for non-IP adapters by the plumbing patch, it is now necessary to specify which adapter you wish to use. While we might be able to figure out from the host address that it is intended for the IP adapter, that heuristic has not been added. Instead, we require that you tell OCDoResource which adapter you expect to use. There are two ways to call OCDoResource now: * Provide OCDevAddr. Be sure to set the adapter field to the IP adapter. * Leave OCDevAddr null. Here the address is prepended to the resourceUri as in CoAP and previous versions of IoTivity. In this case you need to set the IP adapter value in OCConnectivityType argument. The correct values for these fields are given in octypes.h. Note that when you perform discovery, the resulting OCDevAddr in the callback has the right adapter value, and you can simply use the returned OCDevAddr object as the argument to OCDoResource. I recognize that this necessary change to the API is not yet well documented. We hope to remedy this shortcoming soon. John Light Intel OTC OIC Development From: iotivity-dev-bounces at lists.iotivity.org<mailto:iotivity-dev-bounces at lists.iotivity.org> [mailto:[email protected]] On Behalf Of ??? Sent: Monday, July 06, 2015 7:36 AM To: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: [dev] presence is not working Hi All, I am encountered presence problem when testing with presence client sample. (with Change-Id: I3d2363ed0b2585ffcbc403417fd73f60e89f1a88, 2nd July version of master branch) I ran the presenceclient sample like below and it stops following with wait message after 'send fails' Is there problems on sending presences in recent update? ./presenceclient -t 1 -c 0 DISCOVERED Resource: URI of the resource: /a/light Host address of the resource: coap://10.251.43.17:48996 List of resource types: core.light List of resource interfaces: oic.if.baseline 54:43.029 INFO: OCStack: Entering OCDoResource 54:43.029 DEBUG: CA: CAGenerateToken 54:43.029 DEBUG: CA: IN 54:43.029 DEBUG: CA: token len:8, token: 54:43.033 DEBUG: CA: F4 3C EB 23 D3 82 EC B2 54:43.033 DEBUG: CA: OUT 54:43.033 INFO: occlientcb: Callback Not found !! 54:43.033 DEBUG: CA: CASendGetRequest 54:43.033 DEBUG: CA: IN 54:43.033 DEBUG: UQUEUE: Queue Count : 1 54:43.033 DEBUG: CA: OUT Subscribed to unicast address: coap://10.251.43.17:48996 54:43.033 DEBUG: CA: wake up.. 54:43.033 DEBUG: CA: IN 54:43.033 DEBUG: CA: requestInfo is available.. 54:43.033 DEBUG: CA: IN 54:43.033 DEBUG: CA: IN 54:43.033 DEBUG: CA: url : coap://[::]/ 54:43.033 DEBUG: CA: OUT 54:43.033 DEBUG: CA: IN 54:43.033 DEBUG: CA: parse Head Opt: 0 54:43.033 DEBUG: CA: OUT 54:43.033 DEBUG: CA: IN 54:43.033 DEBUG: CA: msgID is 0 54:43.033 DEBUG: CA: gen msg id=5630 54:43.033 DEBUG: CA: messageId in pdu is 5630, 5630 54:43.033 DEBUG: CA: token info token length: 8, token : 54:43.033 DEBUG: CA: F4 3C EB 23 D3 82 EC B2 54:43.033 DEBUG: CA: OUT 54:43.033 DEBUG: CA: OUT 54:43.033 DEBUG: CA: PDU Maker - payload : (null) 54:43.033 DEBUG: CA: PDU Maker - type : 1 54:43.033 DEBUG: CA: PDU Maker - code : 1 54:43.033 DEBUG: CA: PDU Maker - id : 65045 54:43.033 DEBUG: CA: PDU Maker - token : 54:43.033 DEBUG: CA: F4 3C EB 23 D3 82 EC B2 54:43.033 DEBUG: CA: Send unicast data to enabled interface.. 54:43.033 DEBUG: CA: CA_TRANSPORT_TYPE_NUM is not 3 54:43.033 ERROR: CA: unknown transport type! 54:43.033 ERROR: CA: send failed:1 54:43.033 DEBUG: CA: IN 54:43.033 DEBUG: CA: OUT 54:43.033 DEBUG: CA: wait.. Thanks in advance Hun-je =============================================== HUN-JE YEON (???) Senior Engineer, Advanced Convergence Lab Software R&D Center Samsung Electronics Co., Ltd. Tel] +82-10-9454-4650 E-mail] hunje.yeon at samsung.com<mailto:hunje.yeon at samsung.com> =============================================== [cid:image001.gif at 01D0B7C4.18EA5DB0] [cid:image001.gif at 01D0B7C4.18EA5DB0] Samsung Electronics Co., Ltd. Tel] +82-10-9454-4650 E-mail] hunje.yeon at samsung.com<mailto:hunje.yeon at samsung.com> =============================================== [cid:image001.gif at 01D0B7C4.18EA5DB0] [cid:image001.gif at 01D0B7C4.18EA5DB0] Tel] +82-10-9454-4650 E-mail] hunje.yeon at samsung.com<mailto:hunje.yeon at samsung.com> =============================================== [cid:image001.gif at 01D0B7C4.18EA5DB0] [Image removed by sender.] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150706/a603c3c5/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 13168 bytes Desc: image001.gif URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150706/a603c3c5/attachment.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 823 bytes Desc: image002.jpg URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150706/a603c3c5/attachment.jpg>
