Hi Thomas, Can you file a JIRA ticket for this issue against Bridging General and I will see what I can find out.
Thanks, -Todd From: Lea, Thomas [mailto:[email protected]] Sent: Tuesday, May 16, 2017 7:49 AM To: Malsbary, Todd <todd.malsbary at intel.com> Cc: iotivity-dev at lists.iotivity.org Subject: Re: Re: [dev] Bridging (mini plugin manager) + Gateway Routing Hello Todd, I took a look at integrating RD functionality into my plugin, but hit some problems that I would appreciate your input on. In order for my plugin to register resources in the directory, it needs to use OCDoResource (indirectly via OCRDPublish). The forked plugin processes' stacks are in a partially initialized state without things running such as the CAQueueingThread so the plugins cannot communicate with the main stack this way. When pluginServer calls OCInit, it doesnt get very far since g_ocStackStartCount is already greater than zero. A call to OCStop before OCInit does not help since it hangs on shutdown and has other problems due to the copied state. What would you recommend here? Isn't the goal to have each plugin run a fully functional stack, or am I off base on my understanding? Thanks! -- Thomas Lea Xfinity Home Comcast On 2017-05-10 10:26:21-05:00 Malsbary, Todd wrote: Hi Thomas, When you have multiple processes running and you want the child process instance's resources to appear in the parent process /oic/res response, you'll need to use the resource directory (RD) functionality. The parent process will have a RD server and the child processes will act as an RD client to publish their resources to the RD server for inclusion in the parent's /oic/res response. Refer to resource/csdk/resource-directory/include/rd_client.h for the APIs to use in the child, and rd_server.h for the APIs in the parent. Additionally, you'll probably want to use OCStopMulticastServer() in the child so that clients doing discovery only get /oic/res responses from the parent. Ideally this functionality would be part of the mini plugin manager, however that is not the case yet. -Todd On Tue, 2017-05-09 at 20:59 +0000, Lea, Thomas > I am working on an OCF bridging project (OCF 1.0 to non-OCF devices) > on > the 1.3-rel branch and am experiencing some issues and would like > some > input. > > Our core application has many virtual resources and also loads > bridging > plugins which essentially have their own instance of the stack. I > expected devices discovered and added via the mini plugin manager > framework would appear in the /oic/res provided by the 'main' stack > instance, but they do not. I then assumed I might need to enable > ROUTING_GATEWAY in my project. When I enabled this build flag I > found > that my core (non-plugin) code could no longer observe my own virtual > resources because the routing manager aborts the observe request with > a > "Packet is of its own" message. > > Am I missing something? Do I need to handle adding the bridged > devices > to the main stack instance's /oic/res myself? How does gateway > routing > figure into this configuration, or is that only required for routing > to > devices running in OCF stacks outside of the main instance and those > of > the mini plugin instances? > > Thanks, > > Thomas Lea > Xfinity Home > Comcast > > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org<mailto: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/20170516/018aad6a/attachment.html>
