Recently at Exadel, we encountered an interesting challenge for IoT developers. As IoT applications gain so much momentum, there are more and more options on how to develop them. For device communication, two specialized competing protocols stand out: Message Queue Telemetry Transport (MQTT) and Constrained Application Protocol (CoAP). Both are designed to be lightweight and carefully utilize scarce network resources. Both can be used in the right environment, but the problem is that due to the relatively recent development of IoT, many people are unaware of what these protocols are or when to use them.
These are not standard web protocols used by everyone.
In light of our internal discussions, I decided to help clarify these. First, let’s look at what these protocols are.
What is MQTT?
To the layman, MQTT is quite similar to Twitter. It is a “publish and subscribe” protocol. You can subscribe to certain topics and publish on other topics. You will receive messages about the topics you subscribe to, and those who subscribe to the topics you publish will receive those messages. Of course, there are distinctions. For example, you can configure the protocol to be more reliable by ensuring delivery. The publish/subscribe system utilizes a broker, and to further extend the analogy, the Twitter platform itself filters messages based on your subscription preferences.
What is CoAP?
CoAP is more like traditional web-based businesses, such as Amazon. You request resources (pages and search results in the Amazon example), and you occasionally submit your own data (make purchases). CoAP is designed to appear compatible with HTTP, supporting most of the internet as we know it today. CoAP can leverage proxy servers and convert it to HTTP, or communicate directly with special servers designed to use CoAP based on environmental constraints.
When do you use them?
The question you might be asking is, “If they are so similar, when should I use one over the other?”
Due to the publish/subscribe architecture with intermediaries, MQTT is an ideal choice for communication between devices over wide area networks (WAN, the internet). It is most useful in scenarios with limited bandwidth, such as remote field sites or other areas lacking robust networks. MQTT is part of Azure and Amazon service products, so it has a lot of established architecture that makes it easy for current developers to adapt.
In the case of CoAP, the strongest use case is compatibility with HTTP. If you have an existing web service-based system, then adding CoAP is a good choice. It is built on the User Datagram Protocol (UDP), which is useful in some resource-constrained environments. Since UDP allows broadcasting and multicasting, you can potentially transmit to multiple hosts using less bandwidth. This makes it great for local network environments where devices need to communicate quickly, which is traditional for some M2M setups.
If IoT developers are using devices that will leverage existing web server architectures, they will use CoAP. However, if developers are building something that is truly “just reporting” – meaning it is dropped on the network and only needs to report data back to the server – CoAP would be better. Other uses, such as cloud architectures, might be best accomplished with MQTT.
The Future of MQTT and CoAP
Over time, the trend for other protocols, usage, or industry adoption tends to migrate towards more open and inclusive platforms unless a non-inclusive platform is better. Both MQTT and CoAP are open standards that anyone can implement. CoAP was initiated by standard organizations, while MQTT was designed by private companies (including IBM). CoAP is designed to handle resource-constrained environments, which may make it the winner, but currently, MQTT seems to be leading the way. There is significant momentum behind MQTT – large cloud players have chosen this momentum, or at least chosen it. Additionally, many commercial use cases require the capabilities of MQTT (store and forward, centralized hosting). However, one possibility is that some standardized software development around HTTP (e.g., mobile application development) could start leveraging CoAP to handle peripheral devices and communicate with backends to help reduce poor connection bandwidth.
Ultimately, these protocols can be effectively deployed across different applications over the internet. We know there are specific use cases where each is best, but we also know that IoT and IoT devices will continue to evolve in complexity and ubiquity. For developers, understanding the key differences in application can not only enable better initial deployments but also lay a solid foundation for future development work.