Hi Thiago, I find this discussion interesting, and somewhat related to the ones we had at W3C WoT group, so I will add some people from there which might be interesting (and with much more expertise in the field than me).
Reference to this thread can be found here: http://lists.iotivity.org/pipermail/iotivity-dev/2015-October/002867.html On Wed, Oct 7, 2015 at 10:55 PM, Thiago Macieira <thiago.macieira at intel.com> wrote: > On Wednesday 07 October 2015 15:02:55 Drasko DRASKOVIC wrote: >> > Others can chime in, but I believe the rationale goes like this: >> > - HTTP: not bi-directional, so technically unsuitable for the task >> > - XMPP: known quantity >> > - CoAP, MQTT: unknown quantities in firewalls >> >> Maybe I misunderstood something... But big majority of already >> existing IoT clouds are using either MQTT or CoAP (they are using >> often HTTP or WebSocket, but this is more for user apps then for >> devices themselves). These (especialy coap) have suitable client >> libraries for constrained devices, Moreover, OMA-LWM2M i a >> standardized way for devices to reach coud over CoAP. > > Hello Drako > > What you need to understand is how those protocols are considered by routers > usually found on end users' homes. We're not talking about intra-cloud > communication here nor about local-network communication of devices in a smart > home. We're talking about gaining access to a network and transporting OIC > message payloads (which use CoAP) over existing, consumer-grade wireless > access points and routers. > > 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. What you are suggesting here is that there is some flow with these protocols for industrial use, still ARM is building whole Device Cloud based mostly on CoAP and LWM2M: https://www.mbed.com/en/development/cloud/mbed-device-server/ And Amazon just launched yesterday AWS IoT cloud with MQTT (and HTTP) as a central protocol: http://techcrunch.com/2015/10/08/amazon-announces-aws-iot-a-platform-for-building-managing-and-analyzing-the-internet-of-things/#.ptrha7:gNp7. >> What does mean "known quantity" for XMPP? > > See above. It's about the router know about XMPP and knows to route replies > properly back to the originating gateway. > >> Would you say that CoAP or MQTT would not be well suited for this task >> because of intermediate firewalls? > > Yes. > >> I do not see the problems with >> firewalls, as device behind firewall opens the connection to the >> cloud, and not the other way (cloud->device, although even this is >> realtively easy achiveable: >> https://lists.w3.org/Archives/Public/public-wot-ig/2015Sep/0023.html). > > 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. > >> I must be missing something, as XMPP choice comes as a surprise to me, >> so can you please point me to the discussions about making this coice >> in Iotiviry (if there are public ones). > > Those discussions happened inside OIC, so they are not public. IoTivity itself > has no opinion on the matter, as such discussion has not happened (before > today, anyway). We can have it now, but you're arguing against experts in the > market. You'll need really convincing arguments why we shouldn't use XMPP. > > So far, I've heard arguments why could've used other protocols, but not why > XMPP wouldn't be suitable. So, at worst, we didn't choose the most efficient > protocol, but we still chose one that works... 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. # 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 # 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. Let me show you some of these: - IBM Bluemix (HTTP and MQTT): https://www.ibm.com/cloud-computing/bluemix/solutions/iot/ - AT&T M2X (HTTP and MQTT): https://m2x.att.com/ - Amazon AWS IoT (HTTP and MQTT): https://aws.amazon.com/iot/ - ARM Device Server (HTTP and CoAP, LWM2M): https://www.mbed.com/en/development/cloud/mbed-device-server/ - Xively (HTTP and MQTT): https://xively.com/ - Citrix Octoblu (HTTP, WS, MQTT, CoAP): https://www.octoblu.com/ - The list is huge... 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. Already, the fact that XMPP is not used by any of these companies, and that they presume that MQTT and/or CoAP are quite satisfying for the system functioning is suspicious. Ant not only these - telcom companies also: please have a look at the specifications covering protocols from oneM2M standard: http://www.onem2m.org/technical/published-documents. You will see the 4 protocols I mention, but not XMPP. oneM2M is trying to cover all aspects of M2M standardization brought by 8 biggest standard bodies in the world (http://www.onem2m.org/, bottom left). As I say, the only reason for XMPP choice I can think of is that some ISP wanted to re-use his existing TR-069 infrastructure, and I am not 100% sure that this corresponds to modern IoT and M2M standards and directions. BR, Drasko
