On Fri, Oct 9, 2015 at 8:06 PM, Thiago Macieira <thiago.macieira at intel.com> wrote: > 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.
OK, so you are suggesting a scenario in which home router will be the same, but a iotivity-xmpp SW will be installed in some other appliance, for example TV. And there will be XMPP connection between TV and the cloud via your home router (with default unchanged SW - home router does not speak Iotivity). > >> >> 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. Yes, I see now. If this XMPP Iotivity device was for example TV, it will receive encoded XMPP message blob, and put it in a CoAP payload and send it to the refrigerator. Then refrigerator will have a key to decrypt the payload (TV does now how to decrypt it). > 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). Yeap, it is clear now. Basically - ANY participant of IoTivity network (any device in the network) can be a Iotivity Gateway if it has XMPP stack and iotivity-xmpp SW installed. Home router does not have to speak OIC, or know for IoTivity at all (some random off the shelf router already present in home before IoTivity project even started) - it just transfer XMPP messages (TCP packages). Thank you very much Thiago for these clarifications! Best regards, Drasko
