MyeongGi Jeong, Again, there is a misunderstanding. The use of filtering that Thiago suggests is to filter multicast packets. It has nothing to do with the filtering done by CAAdapterIsSameSubnet. Thiago, I invite you to examine the use of CAAdapterIsSameSubnet in the server code (caipserver.c). I believe you will find it doesn?t do the filtering you want to do. I believe you will find it has no effect on the operation of IoTivity at all. MyeongGi Jeong, please explain how this code can possibly affect IoTivity operation. I believe the test as written will always pass. Please explain how it would ever fail. It is an expensive call that adds no value. The problem with the current design is not that it doesn?t work, it will. The problem is the exceptional complexity that adds no value. Part of that complexity is the use of a thread pool when a single tread can accomplish our goals. I side effect is the proliferation of file descriptors when three or four will do. My concern is that adding IPv6 to such an overly complex design will make it even more complex, when we have the opportunity to greatly simplify the code, as Thiago and I have agreed it can be simplified. Please don?t be confused by the conversation Thiago and I are having about the need for a firewall. It is a simple matter that can be added later if the OSWG decides it is important. Other than that, he and I agree that interfaces are not needed for normal operation, and that reducing the number threads and file descriptors will work well and greatly simplify the design. John OTC OIC Development
From: ??? [mailto:[email protected]] Sent: Monday, April 27, 2015 4:22 AM To: Light, John J; Macieira, Thiago Cc: ??; iotivity-dev at lists.iotivity.org; Keany, Bernie Subject: Re: RE: Change in iotivity[master]: Integrated WIFI/ETHERNET adapters to single IPAdapter. Thaigo, about your comments, If it's the former and we go for the solution we're discussing on IOT-497, then we need to discard packets that came in via the wrong interface. Think about it this way: in the gateway case above, the socket will receive UDP packets coming in from the Internet, but it should not act on them. We agree with your opinion. John, It?s not a weird boundary condition where that is necessary. It is a normal case where you want to ignore particular packets on some interfaces. And you also mentioned sockets are inexpensive. So we think have having multiple file descriptors make sense here to block packets on particular interfaces. Actually, having two file descriptors also a good solution but we think this proposal has to be verified in all scenarios such as Gateways where it will simply forwards the packets but client and application cannot connect to them at all. Thanks. Best Regards, --- MyeongGi Jeong Senior Engineer, Software Architect Software R&D Center, Samsung Electronics Co., Ltd. +82-10-3328-1130 ------- Original Message ------- Sender : Light, John J<john.j.light at intel.com<mailto:john.j.light at intel.com>> Date : 2015-04-25 06:33 (GMT+09:00) Title : RE: Change in iotivity[master]: Integrated WIFI/ETHERNET adapters to single IPAdapter. Thiago, I agree there's been a breakdown. :-) The plan to this point is to allow the application control over which interfaces are involved in a multicast, and the IOC OSWG is considering a proposal for doing just that, as you know. So it's your "former case". "then we need to discard packets that came in via the wrong interface". When client A performs a findResource on a specific set of subnets, the expectation is that every server on those subnets is an intended recipient and is expected to respond if it matches the query in the findResource call. (Calling without a query should be discouraged, though we do it a lot for testing.) So in a real IoT environment, client A will ask for "rt=/zabu/light", and server B will ignore the request if it don't have that resource type. findResource multicasts don't happen that often, and they are filtered trivially. Your statement implies that server C has a "/zabu/light" but wants to keep quiet about it under some circumstances. While I can imagine a weird boundary condition where that is necessary, I can't believe we want to spend any more mentons on it. As I said, if you feel firewalls are necessary, make a proposal, and people above my grade level will decide. Until then we don't need to know what interface we're using in the socket layer. John -----Original Message----- From: Macieira, Thiago Sent: Friday, April 24, 2015 1:46 PM To: Light, John J Cc: ashok.channa at samsung.com<mailto:ashok.channa at samsung.com>; iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>; MyeongGi Jeong; Keany, Bernie Subject: Re: Change in iotivity[master]: Integrated WIFI/ETHERNET adapters to single IPAdapter. On Friday 24 April 2015 13:32:13 Light, John J wrote: > > 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. Let's break it down again. Are we going to allow the user of the IoTivity API to decide which interfaces to send multicast on? Or are we going to simply make IoTivity send on all of them, period? If the latter, then a device that is connected to the Internet (like a gateway) will need to have firewalling rules to prevent the multicasts from being sent or received on the Internet. That would be out of scope for IoTivity. If it's the former and we go for the solution we're discussing on IOT-497, then we need to discard packets that came in via the wrong interface. Think about it this way: in the gateway case above, the socket will receive UDP packets coming in from the Internet, but it should not act on them. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center [cid:image001.gif at 01D080BA.D9C25B50] [http://ext.samsung.net/mailcheck/SeenTimeChecker?do=deb3de73a46b1d55b73c8eca77d3f4af636277998840622e032aa89e99be1a3e738ed17e7639ce1f641b1a8c451b073656239170f5eb4b5c326bbdfb2ea96a2fcf878f9a26ce15a0] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150427/deec9752/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 13168 bytes Desc: image001.gif URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150427/deec9752/attachment.gif>
