My comments inline. John
-----Original Message----- From: Macieira, Thiago Sent: Friday, April 24, 2015 1:00 PM To: Light, John J Cc: ashok.channa at samsung.com; iotivity-dev at lists.iotivity.org; MyeongGi Jeong Subject: Re: Change in iotivity[master]: Integrated WIFI/ETHERNET adapters to single IPAdapter. On Friday 24 April 2015 12:53:19 Light, John J wrote: > I submitted JIRA IOT-497 to summarize this. > > The secure multicast receiver can't be combined with the normal one > because they should use different ports as well as being in different > multicast groups, so I believe three descriptors are needed. Why do we need an insecure port at all? The only case of insecure datagrams happens during onboarding, which isn't specified yet. **John** That is currently the default, for both CoAP and IoTivity. Until we get the secure code sorted out, let's not change it. > > Descriptors fd1 and fd4 in IOT-497 could be combined as Thiago > suggests, but why? Sockets aren't expensive. I aimed to reduce file > descriptor usage to reduce complexity and size. Overloading fd1 does > neither. Quite the opposite, in my mind. Fair enough, that makes sense. > I have chosen not to set IPV6_V6ONLY = 0 since not all stacks support it. > Since sockets aren't expensive, having only one way of doing IPv6 > rather than two simplifies the code. The one way will add another > socket and keep the code simple. If you won't set it to zero, which is the default on Linux anyway, then you must set it to 1. But, then again, if we use different sockets for unicast, they'll also have different port numbers. The multicast port number will be shared because of SO_REUSEADDR. **John** Already handled. > Firewalling is not in any IoTivity spec that I know. Let's keep it > simple until we understand the need. We can always add RECVPKTINFO in > if we need it since the effect is localized. Firewalling is required because it's implied. The moment we decided to have an API to enable only a subset of all interfaces, we need to ignore any packets that are received outside of that set. The only other alternative is to not have any API at all for selecting interfaces and make IoTivity always run on all interfaces. If the user does not want them all, it will be up to them to set up firewalling rules in the OS. This includes mobile phones. **John** When we talked about this in the past it was about selecting the subnets we want to multicast on. That made sense to me as it allows an application to designate a domain. If a firewall is needed, somebody screwed up the networking system definition, and I don't see why we would devote our scarce resources to mitigating it. As I said, feel free to propose a firewall policy: without it, we don't RECVPKTINFO. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
