MJ, Can you share with us the requirements for the CA? The remaining comments are inline below.
To all, There is a lot of talk about approaches. What worries me is that we are talking about how we are going to get what we want BEFORE stating what we want. I want a one (no more than two) page description of what we want for Iotivity. Before I do it myself, I will ask for volunteers to gather our requirements. What I want to see is: * Features in a phased approach. For example: o 1st release: Enumeration of interfaces, Selection of interfaces, SLAAC support o 2nd release: Routed discovery o . * Justification for each release including use cases that will be enabled * Matrix of device support * No powerpoint or architecture I am adding this to the DCTG meeting agenda on Tues/PT, Wed/KT. You should expect this to be a working meeting. Pat From: [email protected] [mailto:iotivity-dev-bounces at lists.iotivity.org] On Behalf Of ??? Sent: Saturday, March 21, 2015 1:58 AM To: Light, John J; Kesavan, Vijay S; Macieira, Thiago; iotivity-dev at lists.iotivity.org Subject: Re: [dev] IPv6 changes to IoTivity Hi, John, Vijay, Thiago. Thanks to all for good suggestions and discussions. I'm the leader of Samsung CA development team. I'd like to talk with you about the CA design and the current development approach. When we decided that CA layer has to be required for IoTivity, several kinds of network interfaces and platforms were addressed. As far as I know, we considered Wifi, Ethernet, BLE and BT for connectivity, and Linux, Android, Tizen, Arduino for platofrms initially. ( Am I right, Vijay ? ) To abstract the above connectivitiy types for 4 platforms, our team started implementing separately according to the platform. To decouple from the change propagation, we devided the adapters according to the connectivity types. and, we think, Wifi and Ethernet interface may be little different for the future things like Arduino. [PCL, 2015/03/23] Pulling logic into an abstraction to address a particular platform is usually a complicating approach. Creating an interface for the general behavior and externalizing platform specific behavior is a superior software engineering approach. It all falls under separation of concern. There are a lot of examples to this. Since I like to use BSD sockets as an example, consider: IP sockets have some sockopts for controlling behavior but are not used to controlling the IP stack. To setup up or query the interfaces, other interfaces are used ie netlink under linux, IPHelper under Windows, etc. NOTE: netlink is expressed as a special socket() under linux which simplifies IO management, but it is very different from an IP socket. Now, as your suggestion, we are merging the Wifi and Ethernet adapter and we are also modifing the adapter to support multiple interfaces in our local branch. [PCL, 2015/03/23] Why is the WiFi logic so different from Ethernet logic so different that it needs to be merged? Is this because of Arduino? I would like to see your proposal for the handling of multiple interfaces before you implement it. We consider the unified IP interface not only Wifi/Ethernet but also 6loWPAN over BLE, THREAD, etc. I expect that the patchset will be pushed soon. As Vijay's saying, we will continuesly enhance the CA layer step by step. I want to discuss continuously about Connectivity Abstraction .. * John I agree that the name of EDR/LE adapter might be changed if IP transport adapter created instead of wifi/ethernet adapter. The current names derives from connecitivt type, but we need to change it. Please review when we push it... I'll address the patchset after push Thanks Best Regards. -- MJ ------- Original Message ------- Sender : Light, John J<john.j.light at intel.com <mailto:john.j.light at intel.com> > Date : 2015-03-21 05:12 (GMT+09:00) Title : Re: [dev] IPv6 changes to IoTivity Vijay said "My understanding is that the original CA code contributors are currently working on merging Ethernet and WiFi into a single implementation." While this is a necessary first step, it is not sufficient. The combined adapter type (IP?) should combine Ethernet and Wi-Fi, but it should also include every other transport that uses a socket interface. Specifically, * 6LowPan over BLE * 6LowPan over 15.4 This brings up one of several naming problems in the Connectivity Abstraction. What CA calls 'BLE' is really * GATT over BLE Since BLE might be used with two different adapters, I suggest we proceed to name the adapters after the protocol being used rather than the underlying transport. John Light Intel Opensource Technology Center OIC Development -----Original Message----- From: Kesavan, Vijay S Sent: Friday, March 20, 2015 11:02 AM To: Light, John J; Macieira, Thiago; iotivity-dev at lists.iotivity.org <mailto:iotivity-dev at lists.iotivity.org> Subject: RE: [dev] IPv6 changes to IoTivity John, I agree that there will be platforms with multiple interfaces (some interfaces of the same type) and the eventual goal of Iotivity should be to support such platforms. The first modest step towards that is to support Iotivity on platform with one interface of type Ethernet, WiFi, BT, BLE and the current code/APIs are defined from that perspective. These APIs have to evolve to support multiple interfaces of the same type. The intent of exposing interface type at the API is to allow app-developers to use the information as they see fit. As the APIs evolve to support multiple interfaces, whether interface type is included or not is open to discussion (as suggested by Thiago the application can use an out-of-band mechanism to find out interface type). With regards to all your points on the implementation details, I fully agree and hope to see them resolved. My understanding is that the original CA code contributors are currently working on merging Ethernet and WiFi into a single implementation. Regards, --Vijay -----Original Message----- From: Light, John J Sent: Wednesday, March 18, 2015 8:58 AM To: Kesavan, Vijay S; Macieira, Thiago; iotivity-dev at lists.iotivity.org <mailto:iotivity-dev at lists.iotivity.org> Subject: RE: [dev] IPv6 changes to IoTivity Vijay, Since Thiago is traveling, I will take a shot at answering this. The distinction between adapter types is neither necessary nor sufficient, and it will degrade our software quality. The reason it is not necessary is that the distinction between Ethernet and Wi-Fi is entirely arbitrary. The socket model we are using has been carefully designed over the decades to hide the differences between Ethernet and Wi-Fi and fully support them. One or the other might need a special case here or there, but that can easily be handled in the code. The reason it is not sufficient is that real OIC systems in the industrial domain will have multiple instances of various adapters. For instance, many gateway machines will have multiple Ethernet interfaces (eth0, eth1, etc.). The current regime of separation by adapter will not provide the features we agree are so important in this environment. The API provides no means of distinguishing between those interfaces, and the code provides no means either. Only one case is supported (one Ethernet interface and one WiFi interface), and I don't believe that one case is sufficient for the diversity of network configurations OIC needs to support. The reason it will degrade our code is that it unduly complicates the code at the lower levels since the distinction is arbitrary. The complexity of our code at the socket level reflects the difficulty of undoing all that design. For instance, after choosing to separate Ethernet and Wi-Fi, extraordinary effort (both coding and execution) is spent making sure packets aren't received in the wrong adapter. The irony of this code is that if it ever finds that an adapter has received the wrong type of packet, it can only drop it on the floor, which Is exactly the wrong thing to do. All of the code would be simpler and more maintainable by eliminating the adapter distinction. In place of distinguishing adapter types, we need to distinguish between and allow selection of specific interfaces. This will add complication, but the complexity can be largely countered by removing the distinction between adapter types. If we think of IoTivity as a living code base instead of a static monument, we need to eliminate duplication. Getting rid of the difference between Ethernet and Wi-Fi will be a good first step. Then we need to eliminate the difference between single- and multiple-threading, since that duplication has the same deleterious effects of software quality. (I believe minor changes to the threading model will allow both to share the same code.) If we don't make these changes, I don't believe we can support a quality, living code base, which I see as essential to our success. John Light Intel OTC OIC Development -----Original Message----- From: [email protected] <mailto:iotivity-dev-bounces at lists.iotivity.org> [mailto:iotivity-dev-bounces at lists.iotivity.org] On Behalf Of Kesavan, Vijay S Sent: Wednesday, March 18, 2015 8:22 AM To: Macieira, Thiago; iotivity-dev at lists.iotivity.org <mailto:iotivity-dev at lists.iotivity.org> Subject: Re: [dev] IPv6 changes to IoTivity Thiago, With regards to your comment: " whether the distinction between Ethernet and WiFi makes sense at all. Your work proves that it doesn't, so I'd like to see the distinction removed from the connectivity abstraction branch." Wondering if you are asking about the distinction between Ethernet and WiFi at the OIC API level or the connectivity abstraction layer level or perhaps both? At the OIC API level here is why the adaptors types are enumerated separately - when findResources returns, application is notified the adaptor type on which response was received (application can also select specific adaptor type when calling findResources). If the same resource is found on multiple adaptor types, the application can choose which adaptor is appropriate for further operations. For example, application might decide that certain operations can only be done on Ethernet or WiFi adaptor and not on WAN adaptors (on account of pricing policy), even though they are all IP adaptors. This assumes that connectivity abstraction is able to accurately distinguish between IP adaptors (not all OS/platforms support mechanisms to distinguish between Ethernet and WiFi). With regards to why the connectivity abstraction code has separate code paths for Ethernet and WiFi, I will defer to the contributors of the code to explain the rationale. Regards, --Vijay _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org <mailto:iotivity-dev at lists.iotivity.org> https://lists.iotivity.org/mailman/listinfo/iotivity-dev _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org <mailto:iotivity-dev at lists.iotivity.org> https://lists.iotivity.org/mailman/listinfo/iotivity-dev <http://ext.samsung.net/mailcheck/SeenTimeChecker?do=a89e2f31c590267a077115b 7a67323491b3dc16718424699032aa89e99be1a3e13d69ea60670f66e1fac5bf6c61543587bc 8a6096cfbfc9f02e038c8d853bffbdb9fdddda33e82cbe4a391424e62fcf6cf878f9a26ce15a 0> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150323/26316a22/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7198 bytes Desc: not available URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150323/26316a22/attachment.p7s>
