Rami Jung, This is an area I worked on, though I don't claim to know the full answer to your question. First, as shown, serviceUri hasn't ever been used, to my knowledge. When I wrote my first C++ application, over a year ago, I noticed how silly it is that the first argument of findResource is ignored. The way this has worked in the past is for the specific address to be part of the resource string. For example, coap://192.168.1.203:5683/oic/res The whole string was taken apart by OCDoResource in the C API. I may have changed what happened there with the IPv6 plumbing. The previous code used the OCConnectivityType argument to determine whether a multicast should be used in the findResource. Since that didn't generalize, I change findResource to always do multicast. That may have been a mistake. I see a couple of solutions to this.
* InProcClientWrapper can use the existence of a non-empty serviceUri to indicate unicast discovery is desired. * OCDoResource can use the existence of a host address in the resourceType (ListenForResource) or deviceUri (ListenForDevice) to indicate unicast discovery is desired. * Perhaps someone else has another suggestion. Either of these is easy to implement (for me), so I welcome being assigned a JIRA issue to handle this. The real issues to resolve is what the application developer should see. As you pointed out, the unused host string in findResource seems to be another problem. We can solve both problems by choosing the first of the solutions. John Light Intel OTC OIC Development From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of ??? Sent: Thursday, July 23, 2015 4:49 AM To: iotivity-dev at lists.iotivity.org Subject: [dev] ListenForDevice() which is used by findResource() doesn't support Unicast Hello all I am writing this mail to ask findResource() because there is something weird about ListenForDevice() which is used by findResource(). While using "OC::OCPlatform::findResource()" today , Samsung figured out that findResource always does multicast regardless of host parameter ,. As you know, findResource() is mapped to ListenForDevice and ListenForDevice says serviceUrl is unused parameter. In fact, ListenForDevice doesn't use serviceUrl . The above statement means that it doesn't care about specific URI. even though developers want to point out specific host when they try to find resource. Samsung has new modules which uses findResource() for release 0.9.2 , Therefore your instant answer would be appreciated for making Samsung's plan. 1.Would you please share the history about ignoring serviceUrl of ListenForDevice()? 2.If referring to serviceUri will support later, I'd like to get the information about the schdule when it is fixed. Best Regards, Rami Jung OCStackResult InProcClientWrapper::ListenForDevice( const std::string& serviceUrl, // unused const std::string& deviceURI, OCConnectivityType connectivityType, FindDeviceCallback& callback, QualityOfService QoS) { if(!callback) { return OC_STACK_INVALID_PARAM; } OCStackResult result; ClientCallbackContext::DeviceListenContext* context = new ClientCallbackContext::DeviceListenContext(callback, shared_from_this()); OCCallbackData cbdata( static_cast<void*>(context), listenDeviceCallback, [](void* c){delete static_cast<ClientCallbackContext::DeviceListenContext*>(c);} ); auto cLock = m_csdkLock.lock(); if(cLock) { std::lock_guard<std::recursive_mutex> lock(*cLock); result = OCDoResource(nullptr, OC_REST_DISCOVER, deviceURI.c_str(), nullptr, nullptr, connectivityType, static_cast<OCQualityOfService>(QoS), &cbdata, nullptr, 0); } else { delete context; result = OC_STACK_ERROR; } return result; } [Image removed by sender.] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150723/ed31c0be/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ~WRD000.jpg Type: image/jpeg Size: 823 bytes Desc: ~WRD000.jpg URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150723/ed31c0be/attachment.jpg>
