Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Know your real-time protocols for IoT apps

Kurt Collins | Aug. 19, 2015
The XMPP, CoAP, and MQTT protocols have distinct pros and cons; here’s a quick rundown of the trade-offs.

Real-time communication technology is an absolute requirement for the development of Internet of things (IoT) applications. Imagine the use case where your phone communicates with your lights. If it takes several seconds before your lights turn on, that’s a failed user experience.

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: XMPPCoAP, 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.


1  2  3  Next Page 

Sign up for CIO Asia eNewsletters.