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. > > 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. > 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. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
