November 29th, 2013

Ending the IoT Protocol Wars

Ending the IoT Protocol WarsIt’s been a while since my last blog post – not least because I have been traveling quite a bit to run Layer 7’s European API workshops together with my colleague Ronnie Mitra. The workshops (part of Layer7′s outreach program via the are vendor-neutral and focused on sharing API design and management best practices.

To be honest, I probably learn as much during these workshops as the participants do. It has certainly been striking to watch how our material evolves throughout the workshops. We constantly keep adding and tweaking material, based on what we learn. In particular, I’m struck by the amount of changes my IoT section has been going through.

Here is what I have learned regarding IoT protocols: It’s a zoo out there, with lots of protocols trying to become the next HTTP. And some candidates deploy a formidable array of marketing, making it exceedingly hard to cut through the fog.

My current shortlist of main contenders is (in alphabetical order):

I might add STOMP to that list, just for its simple brilliance. STOMP is a text-based messaging protocol that has recently been extended to allow for binary content. Additionally, I’ve recently started talking with some transportation companies and learning about their use of DDS, which might be another candidate for the shortlist.

In the corner of residing champion, we have JSON/HTTP. Not content to see this protocol pushed into early retirement, advocates have been developing some very interesting approaches that attempt to ensure the continuing relevance of HTTP for asynchronous small messages – WebSocket being the most well-known. Hypercat, Simple Thing Protocol and EventedAPI represent just a small sample of the interesting approaches emerging to support async eventing and messaging with HTTP.

Where does this leave a developer trying to choose the right protocol for that awesome winged steam punk toaster? I don’t really have the answer but there are some documents trying to tease out the differences. Take a look at the MQTT vs. CoAP comparison from or the DDS/AMQP/MQTT/JMS/REST comparison from DDS champion PrismTech.

Based on what I’ve learned so far, only XMPP and DDS have significant commercial deployments while MQTT is being evaluated by almost every major vendor I have talked to. While MQTT’s use as the protocol powering Facebook’s messenger is a good demonstration of its scalability, I don’t think this constitutes a proof point for mission-critical commercial deployments. If you know of commercial deployments of MQTT, I’d love to hear about them.

Each protocol has weaknesses: MQTT appears to be weak in security; DDS seems to be complex to scale and has version dependencies; XMPP is considered heavy-weight. But they all have strengths too, of course: DDS has the deployments in the field to prove its relevance; XMPP supports EXI and WebSocket for efficiency and a proven track record; both DDS and XMPP are extremely mature and have built-in security. Given the industry interest in MQTT, I am sure that whatever security problems exist will be fixed in one of the next versions. The one puzzling piece is the absence of CoAP in a commercial deployment. Again, if you know of one, please let me know.

Where do I stand on all of this? Having watched technologies rise and fall, I think it’s very normal at this stage to have multiple contenders trying to improve on HTTP. What I try to keep in mind though is that both bandwidth and computing power seem to be on an ever-increasing trajectory, while at the same time becoming cheaper and cheaper. Reduction in power consumption and increase in battery capacity, mostly driven through mobile, further lowers the bar for mainstream technology to power even small devices. I would not be surprised if, after the initial phase, we continue to see HTTP and JSON being dominant. As geeks, we sometimes get too excited about efficiency gains while losing sight of the fact that, for most products, technology simply needs to be good enough. But I won’t complain if I am proven wrong this time.

And don’t just take my word for any of this. To help you learn more, here are a couple of other articles reviewing IoT protocols:


  1. [...] Layer7 Blog: Ending the IoT Protocol Wars [...]

    Pingback by Layer7 Blog: Ending the IoT Protocol Wars | Holger Reinhardt — December 1, 2013 @ 11:38 am

  2. has a few MQTT use cases where the companies involved are prepared to be public about them. Always happy to add more.

    Comment by Andy Piper — December 3, 2013 @ 2:46 am

  3. You havn’t looked at VoIP/P2P approaches like Nabto.
    (which is quite normal since these types of platforms are quite new).

    JSON/HTTP lacks the remote access.. but it’s very similar to that approach .. just being able to remote access the JSON request from the browser instead and getting the CSS/Graphics/Javascritp bloat content from somewhere else than the device.

    Comment by Carsten Gregersen — December 3, 2013 @ 8:51 am

  4. Interesting read. Also: I agree about the “good enough” argument. We’ll see.

    I’d like to also share a little – two things you might find interesting:

    * “Web Technologies for the Internet of Things” has a comparison of a couple of protocols.
    * WAMP – another contender.

    Disclosure: I am affiliated with WAMP and Tavendo.

    Comment by Tobias Oberstein — June 27, 2014 @ 9:05 am

  5. Noticed that the to link DDS/AMQP/MQTT/JMS/REST comparison document refereced above is not working. For anyone interested try instead. The document has also been revised a couple of times since it was originally published.

    Don’t think that there will ever be a single protocol that will dominate IoT space. Certainly not any time soon, the application space too diverse (e.g. consumer vs. industrial) and for the choice of protocol the ”good enough” argument still holds. We do see some trends emerging in the markets that we’re focused on (mainly industrial IoT). There is a recognition that wire level interoperability (needs to be supported at the protocol level) between systems and systems of systems is crucial to be able to efficiently manage (for an integration point of view) the massive increase in connectivity that is a fundamental part of an IoT system. The other trend that is apparent from our experience is that many systems, particularly where legacy components/applications are being integrated may well be using a number of different protocols, so having efficient protocol bridging technologies (that support QoS adaption, security propagation etc.) is also very important. Having some standardisation in this area (standardised mappings between protocols) would certainly help. There is certainly recognition in the industrial/business critical segments of the IoT world that more co-ordination/development of standards will help facilitate faster adoption of IoT technologies. For example the recent formation of the Industrial Internet Consortium ( we believe is a step in the right direction.

    Comment by Andrew Foster — August 13, 2014 @ 2:11 am

RSS feed for comments on this post. TrackBack URL

Leave a comment