Every day about 5.5 million new devices join the ranks of the Internet of Things (IoT). By 2020, research firm Gartner expects some 20.8 billion connected devices – ranging from DVRs and home thermostats, to embedded factory controllers – will be deployed, up from about 6.4 billion this year.
Getting those billions of devices to interact is no small feat, especially when you consider the unique character of many IoT devices, which are often small, remotely deployed and infrequently serviced. These devices are also often network-constrained and limited in both computing resources and power consumption. So any system designed to let IoT devices interact must be smart, efficient and economical. Today, two widely adopted protocols address IoT data connectivity: Message Queuing Telemetry Transport (MQTT) and Constrained Application Protocol (CoAP). Let’s take a look at some of the strengths and weaknesses of each.
What is MQTT?
MQTT is a messaging protocol designed for lightweight machine-to-machine communication. Developed in 1999 by IBM to enable a supervisory control and data acquisition (SCADA) system for a remote pipeline project, MQTT has evolved into an open standard maintained by the OASIS standards body. MQTT follows a publish/subscribe message exchange pattern, in which devices create topics at a central broker that client devices can then subscribe to. When a device sends a message related to a specified topic, the message is pushed to any client subscribed to it. The centralized broker architecture can simplify management, help ensure delivery, and ease the challenge of IoT devices communicating across firewalls. Running over TCP, MQTT conversations can be secured using the same SSL/TLS scheme employed for web sites, though it is considered too heavyweight for many constrained scenarios.
What is CoAP?
CoAP, on the other hand, is a new standard developed by the IETF Constrained Resource Environments (CoRE) group that is often described as a lightweight analog to HTTP. Highly scalable and REST-savvy, CoAP trades off the transmission guarantees of TCP (used by MQTT) for the smaller packets and lower overhead of UDP. CoAP employs a client-server model and request/response message pattern, where client devices send information requests directly to server devices, which then respond. Support for an Observer message pattern enables clients to receive an update whenever a requested state changes, for example a valve opening or closing, while confirmed message delivery provides some level of assurance under the connectionless UDP transport.
At the end of the day, the decision of what protocol to adopt depends entirely on the specifics of your particular device deployment. In some cases, the hub-and-spoke, brokered architecture of MQTT may offer advantages, while in others the decentralized approach employed by CoAP may be best. In the same vein, CoAP’s UDP foundation is generally friendlier to battery-powered devices, while MQTT based on TCP can offer greater assurance of message delivery.
Here are some of the key distinctions between these two popular protocols at a glance.
|Established||1999 (2013 OASIS standard)||2014|
|Messaging Pattern||Publish/subscribe via message broker||Request/response (client-server)|
|Transport||Transmission Control Protocol (TCP)||User Datagram Protocol (UDP)|
|Security||SSL/TLS over TCP||DTLS over UDP|
|Strengths||Broker architecture can simplify management; TCP and quality of service options enable robust message delivery||Fast and efficient due to reliance on low-overhead UDP; RESTful model is welcoming to developers and provides for integrated resource discovery|
|Weaknesses||Always-on TCP connections limit utility for low-power devices; SSL/TLS encryption a poor match for constrained clients||Lacks the reliability and service guarantees of TCP-based MQTT|
Regardless of the protocol you choose, you’ll need the right hardware. Click below to explore our full line of versatile, highly reliable industrial PCs, ideally suited for IIoT deployments.