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. 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
