Joseph, Thank you for bringing this up. I would like a clarification.
Since you refer to a specific shield, are you really talking sockets (an OS construct) or are you really talking about interfaces (a PHY level construct)? It is easy for me to believe that the shield won't let you stack more than four of them on an Arduino. It's harder for me to believe that after doing so I can't add an Ethernet shield because the OS is out of sockets. If we really need to limit the number of sockets to a very small number, we should know now. John -----Original Message----- From: Morrow, Joseph L Sent: Friday, April 24, 2015 1:03 PM To: Macieira, Thiago; Light, John J Cc: iotivity-dev at lists.iotivity.org Subject: RE: [dev] Change in iotivity[master]: Integrated WIFI/ETHERNET adapters to single IPAdapter. I would like to add a general note about "sockets aren't expensive". Currently, the Arduino WiFi (IIRC, it may have been the Ethernet Shield, or both!) shields will only let you bind with up to 4 sockets at a time. This makes sockets very expensive as we wouldn't want to leave the end user with just 1 socket after our stack has used 3 of them! -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Thiago Macieira Sent: Friday, April 24, 2015 4:00 PM To: Light, John J Cc: iotivity-dev at lists.iotivity.org Subject: Re: [dev] 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. > > 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 _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
