Doug, I?m not sure what you are referring to.
If you are referring to my original post, I certainly prefer the approach that removes large amounts of unnecessary code from the IP Adapter. The question is how we get there. If you are referring to Sachin?s comments, which you replied to, I prefer the one that works, and that depends on Sachin?s answers to my questions. John From: Hudson, Douglas Sent: Thursday, June 18, 2015 7:05 AM To: Light, John J; Agrawal, Sachin; iotivity-dev at lists.iotivity.org Subject: RE: Proposal for IP Adapter and request for feedback John, Thanks for your detailed description of the two approaches. In your opinion, which approach leads to a better path in supporting multiple network adapters, including non-IP adaptors? Thanks, Doug From: iotivity-dev-bounces at lists.iotivity.org<mailto:iotivity-dev-bounces at lists.iotivity.org> [mailto:[email protected]] On Behalf Of Light, John J Sent: Thursday, June 18, 2015 9:15 AM To: Agrawal, Sachin; iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: Re: [dev] Proposal for IP Adapter and request for feedback Sachin, Thank you for describing so completely how secure communication works. I have some questions for you. 1. If IoTivity stack communicates all secure traffic on 5684, which is not set with REUSEADDR, how does a second instance (or a non-IoTivity CoAP app) work on the same device? With the described usage, the second instance (and other secure CoAP applications) will fail. I don?t believe we have the right to gain exclusive use of the secure CoAP port. 2. You say ?if another Iotivity stack is started on the same platform, it?s secure port will be different?. I don?t see how this works in the code. If I have missed something, it still raises the question of why you use 5684 on the first instance of IoTivity, when you can?t use it for the second and third? If we can securely communicate without exclusive use of 5684 on the second and third instances, why can?t that also work on the first? I assumed (incorrectly, possibly) that the two CoAP ports were both used for discovery and initial connection, 5683 for non-secure, 5684 for secure. By always unicasting to dynamic port assignments (secure and non-secure), all CoAP-based applications can share the same two ports simultaneously. I assumed (incorrectly, possibly) that a CoAP application that wishes to communicate securely would discover using 5684 instead of 5683, allowing the receiving device to understand the desire for security at the earliest possible moment. I assumed (incorrectly, possibly) that a multicast message will be sent from the port the multicast receiver should respond to, allowing simple use of dynamic unicast ports for all purposes other than discovery. After you provide answers to the two questions above, I will abandon my incorrect assumptions. John Light Intel OTC OIC Development From: Agrawal, Sachin Sent: Wednesday, June 17, 2015 5:43 PM To: Light, John J; iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: RE: Proposal for IP Adapter and request for feedback Hi John, Nice job in capturing your thoughts and design ideas. Few Queries: 1. Socket B: secure, multicast listen for IPv6 and IPv4.
