Hi Max, When a resource server gets the ?Discovery Request (which is multicast GET on /oic/res)?, it returns a list of resources it has back to the requesting resource client. However, it is the iotivity stack of the resource client which reads the list and call the ?foundResource? callback with unit resource basis until it reaches the end of the list.
FYI, there was a patch pushed on the master & 1.2-rel branch for the resource client to register a callback to receive the discovery result with a list basis whenever iotivity stack receives the discovery response from a resource server. . API ?> ?findResourceList(?.)? C++ API - master : https://gerrit.iotivity.org/gerrit/#/c/13113/2 <https://gerrit.iotivity.org/gerrit/#/c/13113/2> - 1.2-rel : https://gerrit.iotivity.org/gerrit/#/c/13111/2 <https://gerrit.iotivity.org/gerrit/#/c/13111/2> I think this patch might be one of the solution that you?re looking for. Thank you Jay. > 2017. 2. 19. ?? 11:01, Max Kholmyansky <max001 at gmail.com> ??: > > Hello, > > I wonder if IoTivity libraries provide an efficient programming model for > discovering server resources, in case the list of the resources isn't known > in advance. > > At the OCF spec level, to my best understanding, an OCF server responds to > /oic/res with a single packet, containing the reported resources' list. > > However, when performing "resource discovery" with Java or C++ IoTivity > libraries, the response is mapped into a callback called per resource > discovered. So inside such a callback, I found no way to determine whether > additional callbacks will arrive, i.e. whether the client received all the > discoverable server resources. > > So unless I know in advance which resources are expected to be reported, the > solution requires to put kind of a timer (for how long?) => a potential > performance issue. > > I am aware of the option to perform multicast via a single API call, and > obtain resources from multiple servers. However, I am interested to know per > server when the process is over. > > Anyone has a better solution? Something worth to improve in future versions? > > > Regards, > > Max. > Software Architect - Tekoia Ltd. > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170219/60ddcefe/attachment.html>
