MQTT Vs CoAP for IoT

Understanding the Differences Between MQTT and CoAP

MQTT is a client-server protocol designed for the Internet of Things (although it wasn’t called that at the time), with publish-subscribe messaging as its core. The MQTT server, also known as the MQTT broker, allows you to inspect and manage connected IoT devices and messages. The Broker can also provide shared services, such as retained messages. There are many client libraries and brokers available: free, open source and commercially supported.

CoAP (The Constrained Application Protocol) is also a client-server protocol designed for the Internet of Things. It too targets constrained devices, but is modeled on the World Wide Web of resources (URIs) and HTTP. It uses GET, POST, PUT and DELETE verbs like HTTP, which it can interoperate with through proxies. URIs represent device state, but devices can be a CoAP client or server. For example, a client posts updates to a server or a server responds to GET requests from clients. MQTT is a layer over TCP, whereas CoAP works over UDP. Some features of TCP that are not in UDP, such as fragmentation, have to be re-implemented in CoAP. On the other hand, CoAP is able to use the multicast feature of UDP, which does not exist in TCP. Like MQTT, CoAP has implementations of clients and servers in multiple languages.

What is MQTT?

MQTT is a communication protocol with features specifically targeted at IoT solutions. MQTT:

• Uses TCP connections for reliability (assured delivery and packet error checking), fragmentation, and ordering.

• Aims to minimize the data overhead of each MQTT packet.

• Can store the last known good data value for a device (retained messages).

• Can send Notifications when clients unexpectedly disconnect to allow client state to be monitored (will messages).

• Uses bi-directional message flow - data from and commands to devices can use the same TCP connection.

• Employs publish-subscribe routing, which makes it easy to add more consumers and producers of data.

The MQTT commands are CONNECT, SUBSCRIBE, PUBLISH, UNSUBSCRIBE, and DISCONNECT. Topics are the distribution units, to which clients can PUBLISH and SUBSCRIBE. All authorized subscribers to a topic will receive all messages published to it. MQTT topics do not have to be pre-defined: applications can create them simply by using them.

What is CoAP?

RFC 7252 defines the core of the CoAP protocol. It was designed for machine-to-machine (M2M) applications such as smart energy and building automation, supporting constrained devices and networks while cooperating with HTTP through simple proxies. CoAP reuses the web concepts of URIs and Internet media types to enable the building of IoT solutions.

The core interaction between clients and servers is request-response:

Server resources are discovered by sending a GET request to the /.well-known/core path. Using UDP multicast you can discover servers in a group, or to send requests to multiple endpoints at the same time – to turn a set of lights on or off for instance.

The observe extension allows clients to “subscribe” to a server URI, so that notifications are sent whenever the state represented by that URI changes:

Non-confirmable messages have no acknowledgement, similar to QoS 0 in MQTT. Message retries implement reliability. If no acknowledgment is received after sending a confirmable message, that message is retried at increasing intervals until it is received or reaches a timeout. Non-confirmable messages use a client-generated token of up to 8 bytes in length to match responses to requests. To de-duplicate confirmable messages, the receiver uses a combination of message ID and the source endpoint (IP address in UDP). It is possible to use transports other than UDP for CoAP, although that is far less common than UDP. TCP and SMS are possible.

MQTT and CoAP Comparison Summary

MQTT Performance Vs. CoAP Performance

These are the approximate packet sizes measured with Wireshark for MQTT and CoAP including TCP and UDP overheads for a payload of 256 bytes. The CoAP scenario is a synchronous GET plus the response with the data - there is no connection to establish or subscription to be sent. The MQTT messages are sent at QoS 0 and the CoAP messages without confirmation.

As you would expect, the overheads for UDP are less than TCP in this simple scenario. However, to reach a similar level of capability as the MQTT TCP connection (larger packets, reliable transmission), more complex CoAP behavior is needed.

The following are figures for an MQTT application using a local HiveMQ broker. The application sends and receives a message before the next round trip starts. A similar approach is taken with CoAP using the Eclipse Californium Java implementation of client and server – it issues a GET to receive the data from the server before the subsequent GET. In each case, the messages are 256 bytes.

These are simple scenarios. In both cases, one can expand throughput by tailoring the applications and servers to the solution needed. These figures are just for illustration.

The Advantages and Disadvantages of MQTT

Having a centralized MQTT broker means that IoT services are available in a ready-made and portable form, so:

• Applications can track messages and communicate the availability of services

• Retained messages provide the last known good value for data streams

One of the greatest attributes of MQTT is the flexibility with which you can create solutions. The publish-subscribe paradigm allows many clients to produce and share information with each other as well as back end systems. Brokers can be chained together, and MQTT gateways connected to cloud services just by mapping the flow of messages through topics. Over-the-air updates of firmware and configurations can be broadcast to devices.

The inbuilt queueing of MQTT brokers can deal with connection interruptions and provide buffering for constrained devices that don’t have the capacity to do it themselves.

The Advantages and Disadvantages of CoAP

CoAP behaves similarly to HTTP, which is familiar to many developers and users. Whether that suits more or less than MQTT’s publish/subscribe can be a matter of taste.

With CoAP using UDP it has smaller overheads than TCP, but a smaller maximum payload and less reliability. It can use the multicast ability of UDP for certain efficient functions. CoAP was designed for IoT, so it does a good job of supporting low-powered devices.

Some downsides of CoAP using UDP are:

• It can be more difficult to traverse firewalls, unlike MQTT that uses WebSockets.

• It can be used in DDoS attacks if internet-facing.

CoAP solutions are very flexible since the definition of client and server are dynamic. In MQTT, these elements are fixed. That also means no CoAP standard broker exists with general services that can be relied on.

Conclusion: MQTT Vs. CoAP – Which is Better for IoT?

The out-of-the-box features MQTT brokers provide must be implemented by CoAP applications. Since some MQTT brokers have standard behavior and cloud services available, IoT solutions can be built rapidly.

CoAP could be well-suited to an edge, on-premises, or mesh network that connects to a gateway, which then uses MQTT to the cloud for IoT services. You can also use MQTT for this purpose.

If you want to learn more about how MQTT can increase your efficiency and bottom line, check out these resources:

• MQTT Essentials

• HiveMQ’s open-source software

• HiveMQ’s public MQTT broker

• Other MQTT client libraries

• MQTT 5 Essentials (the latest version of MQTT)

Additional Reading

1. Read the blog MQTT Vs. HTTP for IoT to learn the differences between MQTT and HTTP protocol or if you are contemplating using MQTT or HTTP for your use case.

2. Read the blog MQTT Vs. AMQP for IoT to learn the differences between MQTT and AMQP protocol.

3. Read the blog MQTT Vs. ZeroMQ for IoT to learn the differences between MQTT and ZeroMQ protocol.

4. Read the blog Transferring Data from Modbus to MQTT Broker for Advanced IIoT Data Use Cases to learn the differences between MQTT and Modbus TCP.