Abhishek, I believe that a minimal use of AF_NETLINK (available since 2.2) will allow Linux-based adapters to recognize interface changes without polling on a separate thread. I will make sure to provide a means for non-Linux IP adapters to continue polling. I know Arduino has its own adapter code, so it?s not an issue. Does Tizen support AF_NETLINK?
John Light Intel OTC OIC Development From: Abhishek Sharma [mailto:[email protected]] Sent: Friday, June 19, 2015 9:20 AM To: Light, John J; ASHOKBABU CHANNA Cc: iotivity-dev at lists.iotivity.org Subject: Re: [dev] Proposal for IP Adapter and request for feedback For Question 2, we did some tests on Ubuntu machines and made following observations: Test setup: Box A (UDP Multicast Client) < -- WIFi (107.108.81.xx) --> Box B (UDP Multicast Server) <-- Eth (192.168.1.xx) --> Box C (UDP Multicast Client) 1) If UDP server running at Box B don't join a multicast group, no packets are received from Box A or Box C. 2) If UDP server running at Box B joins a multicast group with local interface IP as "INADDR_ANY", multicast packets are received from either one of Box A or Box C. A "netstat -g" shows that membership has been made at either "Ethernet" or Wlan" interface (not both). Code sample: struct ip_mreq multicastMemberReq = {.imr_interface.s_addr = htonl(INADDR_ANY)}; inet_aton("224.0.1.187", &multicastMemberReq.imr_multiaddr); setsockopt(sockFd, IPPROTO_IP, IP_ADD_MEMBERSHIP, (char *) &multicastMemberReq, sizeof(struct ip_mreq)) Lets say membership happened on "Wlan" interface, if interface goes down and comes up, this membership entry is gone and application needs to make a fresh join request. 3) If UDP server running at Box B joins multicast group with local interface IP (current usage, two join request for two interfaces), multicast packets are successfully received from both Box A and Box C. A "netstat -g" shows correct two entries in membership table. In both 2) and 3) approach however, membership request has to be repeated when interface went down and came up again. So unless there is an alternative way of achieving it, we are going to need network monitor so that multicast group can be joined over newly available interfaces. ------- Original Message ------- Sender : Light, John J<john.j.light at intel.com<mailto:john.j.light at intel.com>> Date : Jun 18, 2015 21:12 (GMT+05:30) Title : Re: [dev] Proposal for IP Adapter and request for feedback Question 1. Since we aren?t binding sockets to specific addresses or interfaces, interface connections can come and go transparently. In fact, 6LoWPAN devices will come and go as the external code (e.g., CONNMAN) enables and disables them. Only recognizing changes every 2 seconds actually slows down recognition. The only place where changes must be recognized is during discovery, and the proposal eliminate the 1-2 second latency there, making IoTivity more responsive to interface changes. Question 2. The application can still provide an IP address to any interface. The proposal doesn?t change that behavior. The existing code and your comment imply that you misunderstand how socket IP works. There is no need to send on a specially prepared socket. Sockets CDEF in the proposal can reach any device on the network that can be reached. As the WIFI signal wavers, the interface may come and go (though hysteresis minimizes the actual state changes), but it will be available if it?s connected, and unavailable if it?s not. It is possible that we may not find an interface with a weak signal, but that isn?t different from the current behavior. Question 3. I tried to answer that question in IOT-548. Quick summary. In circumstances where the underlying network software can?t automatically determine which interface to use, the ?interface? member provides this information explicitly. IPv4 and most IPv6 usage doesn?t need it. IPv6 Link Local addresses, GATT, and RFCOMM, need it when there is more than one network interface they might use, e.g. ETH0 and ETH1, BNEP0 and BNEP1. Question 4. Excellent question. That capability is not answered yet in either the current code or the proposal. I believe Doug Hudson is working on a solution to that issue as we speak. Once there is a way for the developer to tag specific interfaces, my proposal would only need to filter interfaces at multicast time and datagram reception time. Datagram reception filtering would use IP_PKTINFO to find out what interface a packet is received from. Thank you for pointing out the two issues. I am following up on the second. As for risk, there are many types of risk. Having large amounts of duplicate and unnecessary code presents a long term risk that I have found to be important in the long term success of a project. We have been working together to eliminate duplication (e.g., Ethernet v. WiFi), and I hope we can continue (e.g., ?_singlethread?). Eliminating unnecessary code can be our next frontier. Adding IPv6 (which includes doubling the number and types of sockets) adds its own risks no matter how we do it. I am confident that a much smaller, leaner IP Adapter will minimize risk overall. If the community feels otherwise, I won?t undertake the simplification at this time. John Light Intel OTC OIC Development. From: ASHOKBABU CHANNA [mailto:[email protected]] Sent: Thursday, June 18, 2015 5:02 AM To: Light, John J; iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: Re: [dev] Proposal for IP Adapter and request for feedback John, We have few queries about your proposed changes. 1) If remove the network monitor, : How we restart unicast / secure servers if WIFI disconnected / connected in runtime after IoTivity is started? (For ex: changed different WIFI AP in runtime or enabled new interfaces) 2) Network monitor it will be called only when a multicast is requested. : You mean developer always needs to send multicast to make new network addition and removal effective? If so, they might not receive advertisements if WIFI network signal is weak/reconnected. For multicast severs, always we need to join the group with individual interfaces otherwise it will take the default interface only. 3) In your recent plumbing changes, you have added "interface" in CAEndpoint_t. What is the significance here with respect to the interfaces? 4) How a developer can select particular interfaces, if we combine all interfaces with IN_ADDR_ANY? As in previous mailing list, we come across gateway devices where some interfaces need to be selected and some not for the IoTivitiy. And as you are addressing current issues, I have some information about them. 1) A thread dedicated to continually scanning the network interfaces -- This is not true for all platforms. It waits on the events (INTERFACE UP/DOWN) if the platform has support ex: android. 2. The IP Adapter currently allocates non-multicast ports from the range 6298-6307, using a loop to test them for availability. This is an in-progress item as previously, resource sample requires direct unicast messages. This is tracked via JIRA: IOT-379 and changes are pushed now as plumbing changes are given priority. I suggest you to follow the first approach as it limits the changes and eliminate the risk. Regards, Ashok ------- Original Message ------- Sender : Light, John J<john.j.light at intel.com<mailto:john.j.light at intel.com>> Date : Jun 18, 2015 03:20 (GMT+09:00) Title : [dev] Proposal for IP Adapter and request for feedback All, I recently completed the patch titled ?IP address plumbing changes to support IPv6?. Now I am preparing to provide the IPv6 capability itself. This work will primarily affect the IP Adapter since the data paths it requires were handled in the previous patch. There are two ways to approach the remaining IPv6 work, and I want a feedback on how this work should be accomplished. I can ? Make a minimal change to the existing IP Adapter code, or ? Simplify the existing code so that adding IPv6 doesn?t make it more complicated. Here I will spell out the technical issues involved with the two approaches. Here is a quick summary of the existing IP Adapter code issues that might change. 1. Create two sockets for every interface that can support IP addressing, one each for secure and non-secure connections. These sockets come and go as network interfaces appear and disappear. 2. A thread dedicated to continually scanning the network interfaces to maintain a separate list of interfaces for use by the IP Adapter. This happens every two seconds. 3. The IP Adapter currently allocates non-multicast ports from the range 6298-6307, using a loop to test them for availability. 4. After each message is received, the source address of the message is tested for being on the same subnet as the interface on which the message was received. This test involves determining the subnet mask of the associated subnet and comparing the source and destination addresses in the subnet mask bits. Here is how I would simplify the IP Adapter, relating to the above issues issues. 1. A total of six sockets will be created at IoTivity startup. They will remain unchanged until shutdown. a. These are the sockets. i. Socket A: non-secure, multicast listen for IPv6 and IPv4. ii. Socket B: secure, multicast listen for IPv6 and IPv4. iii. Socket C: non-secure, unicast send/recv, multicast send for IPv6. iv. Socket D: secure, unicast send/recv, multicast send for IPv6. v. Socket E: non-secure, unicast send/recv, multicast send for IPv4. vi. Socket F: secure, unicast send/recv, multicast send for IPv4. b. If the application asks only for IPv6 communication, only Sockets ABCD are needed. c. If the application asks only for secure communications, only Sockets ABDF are needed. d. Sockets CDEF would be bound to INADDR_ANY so they can handle IP traffic from any interface, even as interfaces come and go. 2. The network monitor will no longer run on its own thread, and it will be called only when an multicast is requested. a. When a multicast is sent, the network monitor will fetch a list of IP interfaces, and the multicast will be sent to that list. b. This eliminates the 1-2 second latency between enabling an interface and being able to use it. This will become more important as 6LoWPAN is adopted. As soon as the interface is created, it can be used by IoTivity. c. The use of INADDR_ANY in Sockets CDEF eliminates any further need for the network monitor. d. The network monitor no longer needs to call back into the IP Adapter to update a list, so all the code related to that callback can be eliminated. 3. The IP Adapter will no longer allocate ports other than the CoAP multicast ports. a. The ports 6298-6207 are in the range assigned by IANA, and we have no right to use them. While ports 6298 and 6299 are currently unassigned by IANA, ports 6300, 6301, and 6306 are assigned, and our use of them is a violation of network standards. b. The socket mechanism provides a simple method of assigning ports, and it?s much simpler. Simply request port 0, and the network will supply a port which is not used by anyone else. c. The proposal will implement that simple method, providing standards compliance and simplifying the code. 4. The testing of subnet masks after receiving messages will be eliminated. a. This test accomplishes nothing. Reception of a packet by recvfrom is ensured by the network layer to include all and only messages to that port. b. This test consumes considerable resources, involving finding and using the subnet mask, and requires considerable code. c. In any case, there is no equivalent code for IPv6, so nothing equivalent will be provided. After these changes, the IP Adapter will be much smaller and easier to maintain. I will say a few words about why I am qualified to make such drastic changes. I have been programming sockets in both Linux and Windows since about 1990. I wrote a connectivity abstraction for a commercial product (PC-Xware) in the early 90s, and contributed to the first two WinSockathons at about that time. Since then I have used sockets for research projects at Intel. Please indicate your preference for the direction I should go on the IoTivity-Dev mailing list by Monday. I will push a patch for IPv6 next week. If the consensus is for my proposal, I will deliver a patch for it next week. If not, I will do the obvious patch to the current IP Adapter. If I don?t make these changes as part of IPv6. I will submit the remainder of the changes in this proposal as a series of patches over the next few months. John Light Intel OTC OIC Development [cid:image001.gif at 01D0AAA1.7D89E4F0] [http://ext.samsung.net/mailcheck/SeenTimeChecker?do=a105cd2b36de71f3c0c1ac81d9dfefb0676aa994cba000280afd4d5ab3290520a0d230ab136794643256a73227592257c7b41e955949e5c8a728c55b39cc59eacf878f9a26ce15a0] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150619/370c24b2/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/20150619/370c24b2/attachment.gif>
