Em ter?a-feira, 10 de janeiro de 2017, ?s 11:33:51 PST, Richard Peters escreveu: > Sorry i used the wrong term here. > I mean an 6LBR that is running as an IoTivity-constrained node besides > its functionallity as a border router. > Services in a cloud shall be able to use Ressources that are located in > a 6LoWPAN network. > The 6LBR could have a websocket or something like that in > order to be reachable from the cloud, but the devices behind the 6LoWPAN > should not. > So the cloud can communicate directly to the 6LBR, but not to the > devices behind it in the 6LoWPAN. > So does IoTivity-contrained support kind of a forwarding mechanism for this? > As i can see from the answer, this can be implemented on top of > IoTivity-constrained, > but there is no direct builtin support, right?
Correct, websocket and any other protocol outside of OCF's are out of scope. You can implement that yourself or use some other library, at your discretion. > >> 3. can a constrained node be used to manage service discovery for other > >> constrained nodes? > > > > Sure, but again, what's the point? A constrained node is called that > > because it is constrained: little RAM, little ROM and/or little battery > > capacity. If it is managing things for others, it's not really > > constrained. > > > > But IoTivity Constrained can be deployed on a non-constrained OS and > > device > > (it runs on Linux). It's just not what it's designed for. > > I think i need something that is sitting in between. There are Cortex-M > controllers with > up to 512KB - 1MB flash and 128KB Ram. That is enaugh to implement a lot > of functionallity, > but is still very constrained in comparison to Linux enabled boards. Indeed, but it's still constrained enough that I wouldn't manage things for others. A 6LoWPAN or Thread network is designed for up to 1000 devices. Let's be conservative and say that the base system uses 32 kB of RAM. That leaves 96 kB for 1024 devices, or 96 bytes of state per device, in your design. That's awfully tight. Sure, you wouldn't keep all the information in- memory all the time, but there s a minimum that needs to be kept. Just the UUID will take you 16 bytes (assuming you store it in binary form, not like OCF and IoTivity do). So I wouldn't design a 6LBR that offers services on behalf of the nodes on the network with anything less than 64 MB of RAM and at least that much of flash. At that point, you can run the full IoTivity implementation. Or the Constrained one, if you so choose. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
