Thiago, With regards to your comments, perhaps it will help clarifying some of the initial goals of CA. CA, which sits below the resource model layer, is intended to: 1. support and manage multiple adaptors types - Ethernet, WiFi, BT, BLE initially (as opposed to single IP adaptor support that currently exists in master branch); 2. abstract the resource model from the transport protocol so that if CoAP is replaced by a different protocol the resource layer should not change; 3. support multiple adaptors of the same type
The current CA code mainly focusses on item 1, some limited support for 2, and no support for 3. The current APIs only support one adaptor of each adaptor type, a starting step for APIs as well as implementation, and not a long term solution. It should be noted that there are no current plans for CA to have "smarts" to know that resources are reachable via multiple adaptors and manage selection/switching between adaptors. For this reason, and also because existing Iotivity services asked that the adaptor type be exposed, current APIs include adaptor-type information. If I understood your proposal correctly, your suggestion of enumerating adaptors and allowing applications to use an out-of-band mechanism to determine adaptor types is good and something to be considered for incorporating in the future - that will certainly address requirement for being agnostic of adaptor type & support multiple adaptors of same type. --Vijay -----Original Message----- From: Macieira, Thiago Sent: Wednesday, March 18, 2015 12:48 PM To: Kesavan, Vijay S Cc: iotivity-dev at lists.iotivity.org Subject: Re: [dev] IPv6 changes to IoTivity On Wednesday 18 March 2015 08:22:06 Kesavan, Vijay S wrote: > " 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? Hi Vijay I meant everywhere above the abstraction layer. The whole point of the abstraction layer is to abstract things away and I still don't see why we should provide the distinction. Take your example: > 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. Your example is not about Ethernet vs WiFi. You talked about WAN and we discussed this before. Think of a router that has 3G/4G connectivity instead of a cabled. In that case, the WAN interface is not "Ethernet", it is actually a wireless interface. We had concluded the best we can do is report "a default route points here" and let users decide what that means. But now I am questioning that again. Think of these two devices on the same network: - the main Internet gateway will have at least two interfaces and the one with the default route is the adapter connected to the Internet, not the internal network. You don't want to send on it. - a sensor in that environment will have just one interface and it will have a default route. You DO want to send on it. In fact, more than likely, an IoTivity-based application running on a router will know from system configuration which interface adapter is the WAN one by name. So I'm now questioning even providing the "has default route" attribute. We should provide the name and allow applications to make the decision from there. > 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). We're talking about a connectivity *abstraction* layer. It should abstract the OS differences. > 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. Why it has so is not as important as the API. As you said, there may be OSes where this is required. What's important is that those differences get abstracted away and that anyone using CA can target both Ethernet, WiFi, IP-over-Bluetooth, Bridged interfaces, tunnels, etc. without knowing what they are. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
