I believe one of the issues underlying the Connectivity_Abstraction in general and the bifurcation of WiFi and Ethernet is that thought that one might build a system and want to
* FindResource on WiFi but not Ethernet (in creating a gateway, for example), or vice versa, or * FindResource on all wireless interfaces (WiFi, BLE, EDR, etc.) but not Ethernet because it's the management interface. This is a worthy goal, but it overlooks the generalization, which is * FindResource on Ethernet interface 1 but not Ethernet interface 2, again for creating a gateway, or * The same on Wi-Fi, or * FindResource on all the three Bluetooth radios attached to the gateway, each connected to its own set of OIC servers. If we recognize this as a worthy goal, we should be thinking in terms of types and instances. * Enumerate the Ethernet interfaces and allow the user to select which one FindResource uses. * Same with WiFi. * Interestingly, this might allow unification of WiFi and Ethernet as simply being enumerated instances of the IP interface. John From: Penta, Sashi Kumar Sent: Friday, January 30, 2015 11:22 AM To: Light, John J; Kesavan, Vijay S; iotivity-dev at lists.iotivity.org Subject: RE: OCConnectivityType Hi John, Please find my comments inlined below. * What about OC_ALL? That seems to be inconsistent with your explanation. * ****** With current code base, OC_ALL covers only ETHERNET and WIFI, because BLE/EDR are not supported in all the platforms (e.g. Ubuntu). * Is it expected that I will eventually be able to do a single FindResource on multiple networks? I think I heard you say that. >>>>>>>> Yes. * Is it expected in the meantime that I might do multiple FindResource calls, each on a different network? >>>>>>>> Yes and No. * No, You can send one findResource request on all interfaces (today it is WIFI and ETHERNET) using OC_ALL. * Yes. Lets say we have BLE enabled in future, and if you want to send a request on BLE and WIFI and not on ETHERNET. Then with the current OCConnectivityType implementation, you need to send multple findResource requests on each interface (one for BLE and one for WIFI). We are planning to revisit C++ APIs (findResource, etc), and C APIs (OCDoResource, etc) with respect to OCConnectivityType. For now, we are taking the least resistance path to do the merge from CA to master. Sudarshan/Vijay : Please correct if I missed any other points. Thank you, Sashi. From: iotivity-dev-bounces at lists.iotivity.org<mailto:iotivity-dev-bounces at lists.iotivity.org> [mailto:[email protected]] On Behalf Of Light, John J Sent: Friday, January 30, 2015 10:43 AM To: Kesavan, Vijay S; iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: Re: [dev] OCConnectivityType Vijay, Thank you for your cogent response. I'm obviously suffering from a lack of perspective. Some additional question do arise: * What about OC_ALL? That seems to be inconsistent with your explanation. * Is it expected that I will eventually be able to do a single FindResource on multiple networks? I think I heard you say that. * Is it expected in the meantime that I might do multiple FindResource calls, each on a different network? John From: Kesavan, Vijay S Sent: Friday, January 30, 2015 10:14 AM To: Light, John J; iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: RE: OCConnectivityType John - let me take a stab at it. Firstly, I want to mention that the point you raise is specific to the connectivity-abstraction branch (current time) and is not applicable to master - just clarifying to avoid confusing anyone not following CA branch. At the OC API level the connectivity type is used to specify the interface to use for APIs related to find resource, subscribe presence, device discovery (equivalent C++/C APIs). Prior to invoking these APIs, it is assumed that OCInit has initialized the adapters of interest. Internally, this happens by calling CASelectNetwork - where a bit mask of connectivity types makes sense, however the select network API is not (yet) exposed at the stack level (as an OC API). Also note that the connectivity type is returned in the callback as part of OCResource object to indicate on which adapter type the response was received. To understand why OCConnectivityType is not a bit mask let's use findResource as an example. One of the parameters of findResource is resourceURI which indicates the URI to use in discovery, which could be of the form <IP addr>:<port>/oc/core - this URI is applicable to IP networks only (Ethernet and WiFi) and not non-IP networks like BLE/EDR. So selecting EDR and WiFi in OCConnectivityType does not make sense. If OCConnectivityType were a bit mask certain combinations of adapter types have to be filtered out in some APIs. Instead of that the definition allows selecting only a specific connectivity type OR selecting ALL connectivity types and not a subset of types. --Vijay PS: There is a plan to change findResource API to abstract the API and not requiring the user to specify "/oc/core" but that is a separate discussion. From: iotivity-dev-bounces at lists.iotivity.org<mailto:iotivity-dev-bounces at lists.iotivity.org> [mailto:[email protected]] On Behalf Of Light, John J Sent: Friday, January 30, 2015 8:52 AM To: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: [dev] OCConnectivityType In ocstack.h the CA connectivity types are defined: typedef enum { OC_ETHERNET = 0, OC_WIFI, OC_EDR, OC_LE, OC_ALL //Multicast message: send over all the interfaces. } OCConnectivityType; Shouldn't this be defined more like typedef enum { OC_ETHERNET = 1, OC_WIFI = 2, OC_EDR = 4, OC_LE = 8, OC_ALL = 0xfffffffff, //Multicast message: send over all the interfaces. OC_DEFAULT = 2 // used for FindResource } OCConnectivityType; OC_ALL is interesting, but I should be able to pick just EDR and WIFI. Of course, this will also affect the underlying plumbing. John Light -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150130/80bbefe9/attachment.html>
