The development of real-time communication technologies is a story that can’t be explained without mentioning instant messaging. Historically speaking, instant messengers were the original consumer-friendly, Internet-connected real-time communication clients. AOL IM, ICQ, and Jabber are a few examples of instant messenger clients that supported real-time communication. This all happened in the 1990s.
Today, as we move toward developing protocols for communication between IoT devices, we look to lessons learned from building instant messaging solutions. Three major real-time protocols are used by IoT devices today: XMPP, CoAP, and MQTT. Interestingly enough, XMPP started life as Jabber, an open instant messenger protocol.
The eXtensible Messaging and Presence Protocol (XMPP) is a TCP communications protocol based on XML that enables near-real-time exchange of structured data between two or more connected entities. Out-of-the-box features of XMPP include presence information and contact list maintenance. While both features were originally designed for instant messaging, they have obvious applications for IoT. Due in part to its open nature and XML foundation, XMPP has been extended for use in publish-subscribe systems -- again, perfect for IoT applications.
There are several major advantages to using XMPP as your IoT communications protocol. The primary advantage is XMPP's decentralized nature. XMPP works similar to email, operating across a distributed network of transfer agents rather than relying on a single, central server or broker (as CoAP and MQTT do). As with email, it’s easy for anyone to run their own XMPP server, allowing device manufacturers and API operators to create and manage their own network of devices. And because anyone can run their own server, if security is required, that server could be isolated on a company intranet behind secure authentication protocols using built-in TLS encryption.
Unfortunately, there are a few disadvantages to XMPP as well. One of the largest flaws is the lack of end-to-end encryption. While there are many use cases in which encryption may not yet be necessary, most IoT devices will ultimately need it. The lack of end-to-end encryption is a major downside for IoT manufacturers.
Another downside is the lack of Quality of Service (QoS). Making sure that messages are delivered is even more important in the IoT world than it was in the instant messaging world. If your alarm system doesn’t receive the message to turn itself on, then that vacation you’ve been planning could easily be ruined.
The Constrained Application Protocol (CoAP) was specifically developed to allow resource-constrained devices to communicate over the Internet using UDP instead of TCP. Developers can interact with any CoAP-enabled device the same way they would with a device using a traditional REST-based API. CoAP is particularly useful for communicating with low-power sensors and devices that need to be controlled via the Internet.
CoAP is a simple request/response protocol (again, very similar to REST) that follows a traditional client/server model. Clients can make GET, PUT, POST, and DELETE requests to resources. CoAP packets use bitfields to maximize memory efficiency, and they make extensive usage of mappings from strings to integers to keep the data packets small enough to transport and interpret on-device. Aside from the extremely small packet size, another major advantage of CoAP is its usage of UDP; using datagrams allows for CoAP to be run on top of packet-based technologies like SMS.
All CoAP messages can be marked as either “confirmable” or “nonconfirmable,” serving as an application-level QoS. While SSL/TLS encryption isn’t available over UDP, CoAP makes use of Datagram Transport Layer Security (DTLS), which is analogous to the TCP version of TLS. The default level of encryption is equivalent to a 3,072-bit RSA key. Even with all of this, CoAP is designed to work on microcontrollers with as little as 10KB of RAM.
One of the downsides of CoAP: It's a one-to-one protocol. Though extensions that make group broadcasts possible are available, broadcast capabilities are not inherent to the protocol. Arguably, an even more important disadvantage is the lack of a publish-subscribe message queue.
Message Queue Telemetry Transport (MQTT) is a publish-subscribe messaging protocol. Similar to CoAP, it was built with resource-constrained devices in mind. MQTT has a lightweight packet structure designed to conserve both memory usage and power. A connected device subscribes to a topic hosted on an MQTT broker. Every time another device or service publishes data to a topic, all of the devices subscribed to it will automatically get the updated information.
The major advantages of MQTT are the publish-subscribe message queue and the many-to-many broadcast capabilities. Using a long-lived outgoing TCP connection to the MQTT broker, sending messages of limited bandwidth back and forth is simple and straightforward.
The downside of having an always-on connection is that it limits the amount of time the devices can be put to sleep. If the device mostly sleeps, then another MQTT protocol can be used: MQTT-S, which works with UDP instead of TCP.
Understanding the underlying protocols will be important for every developer who wants to take full advantage of IoT technology. As the space heats up, there will be more questions about what is required to create efficient communication between devices. More important, for those creating APIs that not only interact with devices but also control them, real-time communications will be an absolute necessity. What started out as a way for people to communicate instantaneously via the Internet has turned into something much more versatile.
As developers, it is our responsibility to explore all of the options. Understanding the protocols and their trade-offs will be key to building a great product. But you should also be aware of options for adding real-time communications to your technology stack that will accelerate your development process. There are a few back-end-as-a-service platforms available that provide real-time communication out of the box. In many cases, using Firebase, Socket.io, or Built.io to build out your IoT platform may save you countless hours of development time. But for those times when we can move faster and still make use of the right technology stack, we should explore all of the options available.
Kurt Collins (@timesnyc) is Director of Evangelism at Built.io. Kurt began his engineering career at Silicon Graphics (SGI), where he worked on debugging its Unix-flavored operating system. Two years ago, Kurt co-founded The Hidden Genius Project along with eight other individuals in response to the urgent need to increase the number of black men in the technology industry. Mentoring young people interested in the technology industry is a personal passion of his. Today, he continues this work with tech startups and nonprofits alike.