Hi, Very interesting discussion here.
Adding a requirement for XMPP in local IoTivity network acting as a gateway will introduce complexity in handling translation of commands from cloud to local network. Why not keep this as a CoAP solution acting as a pass through gateway. At any rate the CoAP gateway would create an out-going connection and thereby allow incoming control signals. The same addressing required for an XMPP gateway to route the signals to the devices would be required here, however the technology requirement would be simpler. Kind regards, Hasan Derhamy LTU - Lule? tekniska universitet SE-971 87 Lule?, Sweden +46-72?536 5168 -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Thiago Macieira Sent: den 9 oktober 2015 16:13 To: Drasko DRASKOVIC Cc: Claes1.Nilsson at sonymobile.com; Janko Isidorovic; iotivity-dev at lists.iotivity.org; Michael Koster; Nikola Marcetic; Dave Raggett; Rathgeb Paul Subject: Re: [dev] XMPP 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. > > 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. 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. > # 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. > # 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. 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. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
