> -----Original Message-----
> From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-
> bounces at lists.iotivity.org] On Behalf Of Thiago Macieira
> Sent: Thursday, February 26, 2015 2:19 PM
> To: iotivity-dev at lists.iotivity.org
> Subject: Re: [dev] Host field ignored in findResource
>
> On Thursday 26 February 2015 10:03:21 Dieter, William R wrote:
> > For example, if IoTivity were integrated into a NAT firewall with one
> > Ethernet interface going to the outside world and one (or more)
> > interfaces on the inside network, the firewall would probably only
> > want to find devices by multicast on the inside network, or at least
> > have a different level of trust depending on whether a device is
> > inside or outside the firewall.
>
> What you're saying is true, but the way I see it, it supports my argument:
I
> should be able to select which ones to send on, regardless of the
> transmission method.
>
> You gave the example of a router. On most home routers, there are three or
> more interfaces available:
> * a wired one connected to the WAN
> * a wired one connected to the switch that provides access to the LAN
> * a wireless one for the WLAN radio (often one for 2.4 GHz and one for 5
> GHz)
>
> In this case, I want to de-select the first one.
>
> A very common scenario for routers is actually that all the LAN interfaces
> are
> connected together in a bridge interface. That is neither wireless nor
wired
> -- it's a bridge. That is yet another argument against the distinction
> between
> WiFi and Ethernet.
>
> But now think of a router for a wireless Internet connection (4G router or
> WiMax or whatever). Now, instead of having a wired WAN connection, I
> have a wireless one. So now I want to de-select a wireless interface and
> keep
> all wired ones..
BSD sockets as the standard for IP communication clearly expresses UDP
packet
routing and interface expression. However, it is expressed several ways.
1) They are bound BEFORE use, but given it is bound to all interfaces
(inaddr_any), you can send via any interface as long as the routing tables
agree.
2) However, binding to inaddr_any does not work for multicast as the IP
stack
select only one interface as the default multicast interface. You usually
bind
multiple sockets to each multicast interface to control which one to use.
3) Receiving is even more complicated but not hard.
So, how would we suggest proceeding. Assuming that we are just talking about
broadcast/multicast/discovery operations, it may be nice to have an old
select() style mask where you can enumerate your interfaces by index and use
a
bitmask on broadcast/multicast/discovery operations. In this world, the
(crude)
interface might look like (pick on the approach/thought, not the code,
please):
// The following struct COULD be one of the standard netlink or BSD structs
// This is just for example purposes
struct iface {
uint8_t wan : 1;
uint8_t wireless : 1;
uint8_t secure: 1;
char name[8];
// blah
}
int getIFaceCount(); // Returns the max index
struct iface* getIFace(int index); // Returns NULL or iface record
// If there is not a convenience method to get the mask for non-wan
interfaces
// The following would build the mask from scratch
int mask = 0;
for (int index = 0; index < MAX_IFACE && index < getIFaceCount(); ++index) {
struct iface* temp = getIFace(index);
if (temp && temp.wan != 0) {
mask |= 1<<index;
}
}
sendToAll(buffer, <blah>, <blah>, mask);
// If you want to send to all use some macro like ALL_INTERFACE which is
0xFF
Does that make sense? I think that this approach handles some of the issues
that
Thiago raised including multiple radios of the same type (ie. eth0, eth1,
wan0, wan1, etc.)
Pat
-------------- 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/20150227/8d31d94f/attachment.p7s>
