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 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: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Kesavan, Vijay S Sent: Wednesday, March 18, 2015 8:22 AM To: Macieira, Thiago; 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 https://lists.iotivity.org/mailman/listinfo/iotivity-dev
