Hi Thiago, On Fri, Oct 9, 2015 at 4:13 PM, Thiago Macieira <thiago.macieira at intel.com> wrote: > On Friday 09 October 2015 15:51:37 Drasko DRASKOVIC wrote: >> > We had to choose an existing and well-known protocol that allowed for bi- >> > directional exchange of messages of arbitrary format. Those qualifications >> > exclude MQTT and CoAP, since those aren't known to most consumer routers. >> >> Well... I still do not understand what could be stopping UDP (CoAP) >> communicating devices to initiate the connection to the cloud, then >> keep it open for bidirectional communication (WS, CoAP observer, MQTT >> pub/sub). Or do you have to initiate the connection from the cloud >> towards device behind the firewall and this is what makes problem? But >> per my understanding, these node devices will have to initiate >> connection already at least announce/register the resources they >> offer. > > We can stop here. This is not about devices initiating communication to the > cloud. Using CoAP for that is definitely possible and this is exactly what we > are calling "Cloud Native". > > This is about remote access back in to your local network. This is about NAT > transversal and carrying enough metadata to direct the packets to the target > device inside your network. In other words, a VPN solution.
OK, I get it. You want to shoot messages to a node device behind the firewall (destination) from a cloud as the origin (surce), i.e. initiate connection from the cloud side. Yes, I agree, based on this discussion https://lists.w3.org/Archives/Public/public-wot-ig/2015Sep/0023.html, we saw that this is not so simple with CoAP, and demands constant heart-beat to prevent firewall closing the connection (which in case of UDP is even worst). I saw it differently before, I thought that Iotivity gateway would open a connection towards the cloud, and then this connection will stay opened. > >> > That is where our opinions differ. Where you say "easy achievable" (sic), >> > we say "almost impossible". We have OIC members who have been doing this >> > kind of remote access as a business for years and we've trusted their >> > experience on the subject, choosing a protocol that has the least amount >> > of issues. You can, if you want, argue with them, over technical merits. >> > If you do, I will be glad to introduce you to them. But until the opinion >> > of experts in the OIC and in IoTivity changes, we'll continue to follow >> > their recommendations. >> >> I am for sure interested in seeing a public discussion about this, >> especially that this choice comes as a bit of surprise as something >> unusual in IoT world - especially for constrained devices. > > This discussion happened inside the Open Interconnect Consortium, so it was > not public. I can introduce you to my contacts there. I hope that they are reading Iotivity mailing list, so maybe they will react and give us all some clarifications. > > And there's another misunderstanding above: this is not about constrained > devices. This is about one gateway device in your network that does the NAT > trasversal, the VPN solution mediated by the cloud. > >> I am not arguing that XMPP is not suitable for this. It is well known, >> robust protocol with lot of years in use. >> >> I see following drawbacks on choice: >> >> # Additional protocol rises complexity >> My point is that Iotivity is already using CoAP (great choice - at >> least we agree on this 100% :)) for internal communication. > > We agree on this and we agree that using CoAP for communicating with the cloud > whenever possible is a great idea. > > The problem is the "whenever possible". The back-into-local-network with > current consumer-grade routers requires one device to be able to open a port > on the router. That usually means TCP anyway and will require UPnP > functionality. > > A much more reliable solution is to open an outgoing connection to the cloud > and use that as an intermediary. You are right on this, my missunderstanding came from the way who initiates connection (here it is apparently cloud->device, as opposite to clasic approach device->cloud) > >> # Edge router (or board router, or GW) has to be more powerful device, >> probably Linux gateway >> People building sensor networks - for example 6LoWPAN network - are >> used that one of the same sensors can play the role of edge router. >> Introducing different devices sometimes can harm interoperability - >> for example on the radio level. And it is sure more complex for >> provisioning and installation > > You've placed a requirement on people upgrading their routers before they can > remote-access their internal IoT networks. While I do agree that in the long- > run, the routers will be able to do the work for us, in the short term that is > not the case. You cannot require an upgrade of the device. Routers will have to be upgraded anyway! How else do you plan to install Iotivity SW on them? I see it like this: it will either be ISP providers who will shoot the FW update on the routers, but more probably I see it as device monifactuters who will sell new "Iotivity compliant" home gateways. > >> # Cloud services have to support XMPP >> This is the big one. For sure that Iotivity-specific handling must be >> implemented in the cloud, but as I mentioned before vast majority of >> existing IoT clouds are supporting one of the 4 popular IoT protocols: >> HTTP, WS, MQTT or CoAP. While it is not so difficult in adding blocks >> to support Iotivity in your existing cloud, it is not trivial to add >> an additional XMPP server, probably in the form of a library to fit it >> in your existing infrastructure, then add whole support for an >> additional protocol. > > We disagree here. It's a lot easier to install an XMPP server in a cloud > provider than it is to fix home routers/gateways. And we know of XMPP servers > that will handle the load. This is not what I was thinking about. You can add MQTT or CoAP or whatever SW support to any already existing GW by issuing FW update. I do not understand how you can add Iotivity support to a current home router without changing it. And most probably these GWs will have a FW components in which cloud services provider will write at least his URL, so that the Iotivity can reach it... Maybe this can be even selectable on the ruoter by a user himself - but you must install some SW on the existing router (who does not know anything about Iotivity) itself. > Besides, this has nothing to do with IoT. Support of the IoT protocols will be > important in the future, but we need a solution right now that works. > >> Now, I know that all these clouds are made for centralized model, >> where nodes connect directly to the cloud. But I would prosume that it >> would be much bigger effort for any of these companies to add XMPP >> support to their structures than to re-use already running servers. > > I really don't think it is. See above: installing software in a server is a > lot easier than fixing the routers. Not sure... I am talking about big cloud multi-user systems to which you want to add an additional protocol.... maybe i am wrong. Anyway, now that I understand that you need VPN-like solution, I agree that XMPP could be the best choice. BR, Drasko
