On Oct 10, 2016 5:10 PM, "Thiago Macieira" <thiago.macieira at intel.com> wrote: > > On segunda-feira, 10 de outubro de 2016 16:43:19 CEST Gregg Reynolds wrote: > > originally, I agreed with this. but now I've spent more time working with > > the code and reading the specs on the wiki I've changed my mind. > > > > most obviously : if I'm only building a local oic network with no bridging > > then I do not want *any* routing logic. it's all wasted overhead. > > > > we need not 2 but 3 build options: > > > > ROUTING_MODE :: NONE || EP || GW > > > > IMO the default should NONE. > > Again, I argue that there's no such thing as NONE. The network you describe is > a network composed only of EP. There's no extra logic in the endpoints: all > the logic must reside in the gateways alone.
I don't see how that can be true. at least as I understand it, EPs must check with the routing mgr to decide where to address their packets. at the very least, an EP node must have the logic to send stuff to a gateway. that is wasted space and code if you are not internetworking. > > The rationale for this is interoperability: if the feature is not part of the > OIC or OCF spec, then the gateway needs to support all types of clients, > whether they are written with IoTivity or using something else. That means the > gateway must work with unmodified clients. > > If the feature is part of the spec, then any code required is always present > because of certification. > > > More generally: this feature is not OIC. IMO it should not be part of the > > standard Iotivity build. Iotivity is supposed to be the reference > > implementation of OIC. Nothing more, nothing less. Stuff like > > oic-internetworking (including also the cloud stuff) should be treated as a > > non-standard add-on, and clearly so-marked. in the case of "routing", I > > think also it should be clearly marked as EXPERIMENTAL (i.e. > > non-standard), insofar as it is based on a non-standard extension of CoAP. > > Indeed, but that is only the case if the feature requires extra code in the > EPs. > > > > The latest Bridging spec does this by... > > > > where can we find this? > > Sorry, the spec for Bridging is not public yet, so I can't give it to you. > > I can describe how it works. Once it finds devices on the "other" side, it > creates a "virtual" device on the local side. Currently, it does that by > opening an UDP port per device found (per di generated) for the foreign > network. > > We have a future intention of using a CoAP header entry to indicate the di > being sought, so a bridging gateway can multiplex multiple "foreign" servers > on the same UDP socket. Unfortunately, modifying IoTivity to send that header > was too difficult, so we didn't implement it. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20161010/5ab1dec3/attachment.html>
