Tuesday, November 5, 2013

IoT Protocol Wars: MQTT vs CoAP vs XMPP

Just some thoughts and conclusions on the above topic about a "single standard IoT protocol", which is being actively discussed now in many places.

The following candidates are being presented in the most cases:
  • MQTT and its variants like MQTT-S
  • CoAP
  • XMPP
My personal experience with these protocols in IoT space makes me lean towards MQTT / MQTT-S or REST API in the end. Or just to follow your project requirements and to make the most suitable decision. Please see some explanations on the below diagram.

Maybe it's also worth mentioning that there are some other similar protocols - like HTTPU, which is used by UPnP / DLNA for the home networking needs. And it will stay for a long time in the home space and must be considered by IoT ecosystem as an important protocol.

If you will try to Google for the pending discussion groups about the choices for these protocols, then you may find a lot of them. There is also the following publicly available document, which becomes more and more popular in such discussion groups: link to GoogleDocs

And the hot discussion happens not only in the space of development communities and the topic researchers, but in the large enterprise circles as well: MQTT is pushed forward by IBM and CoAP with XMPP are actively promoted by Cisco, smaller companies have their own case studies for MQTT or CoAP deployments etc.

Still this question is open and there is no decision here. Maybe it doesn't make sense to identify such a single standard IoT protocol, but to stick with the suitable choices for the project requirements?

Somehow this story reminds me the old days about "SIP over UDP" vs "SIP over TCP/TLS" discussions. With the wish to find the perfect balance between scalability (UDP wins) and NAT traversal options (TCP wins). There were some other reasons for SIP over TCP in addition to NAT traversal - larger MTU size and larger SIP REGISTER periods for prevening extreme server spamming. But still the main point in this story was not about UDP or TCP, but in the hot discussion itself ;-)

To make the long story shorter - here is my self-made summary for the protocol choices in IoT space:


  1. Hello Oleg,

    Thanks for the post. I'd like to add some information concerning XMPP that was perhaps misleading in your article:

    "Message traffic is large": There is an extension for very efficient compression using EXI (XEP-0322), which makes message sizes much smaller. The overall complexity of communication is of course dependant on how much you want to implement.


    "Security is the concern - public untrusted". This is basically a false statement. I would say it is actually the opposite. Of course, it depends on your choice of message broker. As in MQTT you can choose a publically available server, or install it in private networks. I would also point out that XMPP authentication is somewhat safer than for instance MQTT, where passwords are sent over the line instead of hashes (albeit over a possibly encrypted channel, instead of using publicly standardized and accepted methods such as SASL). But interesting here can be to note XEP-0324 which provides an architecture for provisioning of services and content (or part thereof), something lacking in other solutions. It provides a mechanism which enables open IoT networks and infrastructure which competitors (or 3rd parties) can share, but still protecting the interests of individual parties.


    As has been noted above, interoperability is key in IoT. Here XMPP has extensions creating models for:

    XEP-0323: Sensor data

    XEP-0325: Control:

    XEP-0326: Concentrators (Integration with other systems and/or protocols)

    And also (work in progress) Interoperability interfaces:

    Several other extensions are in line to be published as well. For an overview of existing and planned extensions, see this presentation:


    Best regards,
    Peter Waher

    1. Thank you for your detail.
      But I think MQTT is the best for mobile communication.
      And Facebook was announced that they will use MQTT in facebook messenger app.

      So that I think, which is the best is up to what they are used for.

      Regards, Hong.

  2. Hi Peter,

    It's a pleasure to receive such detailed comments, thank you.

    Let me reply in details as well:

    "Security is the concern - public untrusted". This is basically a false statement. I would say it is actually the opposite.
    [Oleg] It looks like you've misinterpreted my original statement here - in the boxes near the protocols I've listed the criteria and not the associated problems. So this statement actually means "when there is a need for extra security and your system is deployed in the public untrusted environments, then XMPP is a better choice". But I will update this diagram to provide more clarity here. Thanks for pointing this out.

    "Message traffic is large": There is an extension for very efficient compression using EXI (XEP-0322), which makes message sizes much smaller.
    [Oleg] Yes, you're 100% right here. Compression may help to get less traffic in the end. But still, why not just use a simple binary format optimized towards your specific application models? Especially taking into account that compression logic will consume some extra CPU/MPU cycles and might be an overkill for your 8-bit MCU powered sensor device. Right?

    As has been noted above, interoperability is key in IoT. Here XMPP has extensions creating models for:
    [Oleg] I think that in this light XMPP has a really bright perspective in IoT space. But what really stops me from using XMPP in the current projects - lack of the available libraries (suitable for embedded systems), which will support all the above extensions for IoT. Main reason to select MQTT was driven by the fact that in 2 weeks you can implement MQTT agent from scratch and connect it to the cloud. Doing the same with all these XMPP extensions will consume much more than 2 weeks, right?

    Best Regards,

  3. Hello Oleg.

    Thanks for the quick reply. Sorry for the misunderstanding regarding the security concern. Your response makes it clearer.

    Regarding compression: It is true that compression uses CPU. However, EXI compression does not use as much CPU as you might think. But still, you cannot avoid the CPU overhead. There are projects available creating C-code stubs for efficient EXi compression in micro controllers. These are very efficient in terms of code size and cycle count, but not generic. In a micro controller with fixed firmware this is normally not a problem. But generic libraries require generic solutions, so the EXI compression engines in such libraries must also be generic.

    The reason to use a protocol such as XMPP instead of a pure binary (i.e. proprietary) protocol is its ability to be pluggable and extensible. It is very easy to extend the protocol by third parties and avoid conflicts and/or undefined or badly defined messages that can be difficult to interpret. This makes it ideal for creating interoperable applications where a multitude of product manufacturers can interoperate in a larger ecosystem. Of course, the same could be done using a "binary protocol", but you would end up with something similar to XML anyway, just encoded differently. And this would be more or less the same as EXI-serialized (compressed) XMPP.

    Regarding devkits, I know of development of different devkits using XMPP, but none for MSP microcontrollers (yet). I know of research being done using XMPP in sensor networks using MSP430 microcontrollers.

    One devkit using Smack XMPP client library and RaspberryPi is being developed by Sustainable Innovation (SUST):


    Best regards,
    Peter Waher

  4. Hi Oleg,

    What about DDS (http://en.wikipedia.org/wiki/Data_Distribution_Service) ?

    Where DDS fits in IoT?