Yes, I just hit that area myself.

Additionally I have recently (in the last couple of years) implemented
such cross-platform communication libraries for a few projects. What
John Light points out is exactly what I was starting to devle into
myself. When running tests of base interface code on OS X for the first
time I also saw it catch bluetooth and firewire network interfaces.

One key point used was to have a simple API to fetch all interfaces in a
cross-platform and technology independent fashion. Then a slightly
higher level could take that and filter to only the types of interfaces
being targeted.


On 02/25/2015 03:45 PM, Light, John J wrote:
> I concur with Jon's concern.  Real control systems often have multiple 
> interface instances, and our inability to handle more than one instance of an 
> adapter will become a major limitation.
> 
> Ironically, allowing multiple interfaces is made *much* harder and more 
> performance intensive because of our arbitrary separation of WiFi and 
> Ethernet.  I've been studying that level of the code in great detail 
> recently, and we've got a real mess on our hands.
> 
> John Light
> 
> 
> -----Original Message-----
> From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-bounces 
> at lists.iotivity.org] On Behalf Of Jon A. Cruz
> Sent: Wednesday, February 25, 2015 3:11 PM
> To: iotivity-dev at lists.iotivity.org
> Subject: Re: [dev] Host field ignored in findResource
> 
> 
> 
> On 02/25/2015 02:02 PM, Kesavan, Vijay S wrote:
>> We support global discovery (all interfaces, all transports) and host 
>> discovery (specific host on a specified transport - requires identification 
>> information for that host eg. IP addr or MAC addr).  Interface discovery 
>> itself might have sub-scenarios and the following ones are currently 
>> supported:
>>
>> 1. Discover resources based on specific transport type - example WiFi, 
>> Ethernet, BT, BLE.  Note for IP interfaces user has the option of selecting 
>> Ethernet vs WiFi.
>> 2. Discover resources across hosts on a specific transport type - for 
>> IP interfaces it is possible to discovery on the well-known multicast 
>> address
>>
>> What is not supported is selecting the specific interface based on transport 
>> type.  For example, if there are two WiFi interfaces on the platform, it is 
>> not possible to specify which WiFi interface to use.
>>
> 
> Ok.
> 
> I'd just like to be sure it's on the record that the last constraint can be a 
> major blocker. Most of my dev systems have multiple interfaces and I'm often 
> not operating from the base one listed. This is also especially common for 
> VMs.
> 
> --
> Jon A. Cruz - Senior Open Source Developer Samsung Open Source Group jonc at 
> osg.samsung.com _______________________________________________
> iotivity-dev mailing list
> iotivity-dev at lists.iotivity.org
> https://lists.iotivity.org/mailman/listinfo/iotivity-dev
> 

-- 
Jon A. Cruz - Senior Open Source Developer
Samsung Open Source Group
jonc at osg.samsung.com

Reply via email to