On Friday 09 October 2015 18:21:52 Drasko DRASKOVIC wrote: > > That's the situation we have to live with. We cannot require updates to > > the > > firmware. > > But how will this router connect to xpmm://mycloudservice.com for > example? How will GW know where to go and connect the services? You > must at least give it this XMPP URI.
It won't. Any device inside your network can do that. The router only has to do what it has been doing for the last 15 years: route and (if IPv4) NAT. > And how will it know how to wrap Iotivity messages, and transfer them > from XMPP to CoAP, etc... You have to run this SW: > https://github.com/iotivity/iotivity-xmpp on the router, right? This > is why you (and Alljoyn) are providing OpenWrt packages. Again, this is not required to be the router's job. Sure, it is a device particularly well-suited to do the task, so if we can get those firmware updates in them to provide an IoTivity cloud connectivity tunnel, great. But if we can't, we need to have such a tunnel work with a router that doesn't understand anything about IoT, cloud or OIC. > >> Not sure... I am talking about big cloud multi-user systems to which > >> you want to add an additional protocol.... maybe i am wrong. > > > > I am not. I am talking about a simple service that relays communication > > from A to B. You can easily buy storage and processing power in a cloud > > and install your service there. > > If A is a phone app that connects to the cloud via WebSocket for > example, trying to switch on refirigerator connected in a distant home > in Iotivity LAN via CoAP, there must be a GW that will speak with the > cloud XMPP, then translate this into CoAP and send it to refrigerator > (in the similar fashion that the cloud must transalte WebSocket > message coming from the phone into XMPP to send it to the GW). Correct. I wouldn't start with WebSocket, though. To simplify, I'd make my application prepare the CoAP payload to be sent to the refrigerator and encrypt it end-to-end. The encrypted packet is then sent over XMPP to the cloud service that has connectivity with the device in my network that I described above. This device will receive the XMPP communication and extract the payload and place on a CoAP packet, with the refrigerator as destination. Think of the XMPP connection as a simple VPN. Neither the cloud server nor the gateway device inside the network will interpret the message (they can't, it will be encrypted). > How does GW know to speak XMPP? How does it know to translate it to > CoAP? Only if you install this: > https://github.com/iotivity/iotivity-xmpp on it. Via FW update (i.e. > modification). Or am I missing something? Yes, apparently a lot. See above, I hope it clarified things. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
