AMQP Vs. MQTT

AMQP and MQTT are two of the most popular IoT messaging protocols, so it’s no surprise that AMQP vs. MQTT is a popular topic among enterprises responsible for building, designing, and maintaining IoT systems. The IoT messaging protocol a team selects can make or break a project.

Of course, there is no one-size-fits-all solution. The right protocol for a given IoT project depends on variables such as security requirement, network reliability, and scale. In this article, to help you make the best decision for your next IoT project, we’ll explore the AMQP vs. MQTT topic in-depth and compare these two protocols using 10 essential criteria.

IoT Messaging protocols recap

In modern IoT systems, reliable data payload exchange is more important than ever. IoT systems run resource-constrained environments. These constraints come in different forms: processing power, power consumption, storage, memory, thermal considerations, etc. When combined with application-specific features (warnings, alarms, sensor readings), IoT systems have a unique set of messaging requirements.

That is one of the reasons that traditional communications protocols, like HTTP, are not appropriate for IoT use cases. HTTP has the following properties:

• Synchronous exchange
• Request-response exchange paradigm
• Client-server architecture

HTTP is one-way: the client must initiate the connection. It is a one-to-one protocol that is not suited for broadcasting. Its larger messaging overheads and more rules make it more resource-intensive and unsuitable for constrained networks. This is not consistent with the demands of IoT.

oT messaging is generally asynchronous and uses exchange paradigms like publish-subscribe, publish-consume, one-to-many broadcasting. HTTP simply has too much overhead to be a viable IoT messaging protocol.

AMQP vs. MQTT

AMQP and MQTT are binary messaging protocols that work on top of TCP/IP. They allow message exchange between systems and applications irrespective of the underlying hardware & software stack. Binary messaging protocols are more efficient than text protocols as they have lesser processing requirements.

Both of them are suitable for IoT applications, but they’re optimized for different requirements. MQTT generally serves high-latency, low-bandwidth networks with thousands of embedded devices better. On the other hand, AMQP works better in large, enterprise-wide applications with highly customized and involved messaging requirements.

The following sections will take a closer look at the two protocols.

AMQP‍

AMQP stands for Advanced Message Queuing Protocol. It is a general-purpose messaging protocol created by the banking industry. The banking industry has large data sets, places a premium on confidentiality, and operates IT systems silos (protected by licenses) which is what we’ll find in the AMQP protocol.

Due to its origin, AMQP is a more complete messaging system than the lightweight MQTT. AMQP comes packed with options for all scenarios. It includes reliable queuing, flexible routing, various types of messaging, security, and transactions.

Consequently, its most significant usage is also in large-scale enterprise projects that have specific security, reliability, and interoperability requirements.

An AMQP packet has the following structure:

The stricture of an AMQP packet. (Source)

MQTT

MQTT stands for Message Queuing Telemetry Transport.

It has its origins in the oil & gas industry, where engineers created it to serve a particular purpose: lightweight transfer of information from edge devices and sensors to the SCADA system.

MQTT is limited in options for the developer, but it is resource-efficient and supports several useful functions. MQTT is suitable for embedded devices tasked with monitoring equipment and sending infrequent messages on low bandwidth networks.

MQTT has a fast response time, minimum overhead, ensures smooth data transfer, uses low bandwidth, and reduces resource utilization (CPU, RAM) compared with AMQP. MQTT can connect many thousands or even millions of devices.

An MQTT “packet” consists of three parts:

• Fixed header: Mandatory; with size between 2 to 5 bytes only.
• Variable header: Optional; with a variable size.
• Payload: Optional; maximum size is up to 256MB. It holds commands or data values.

An example of MQTT message structure. (Source)

AMQP vs. MQTT: In-Depth Comparison

This AMQP vs. MQTT comparison below emphasizes two key points:

• AMQP is the more comprehensive of the two messaging protocols.
• MQTT is better suited for IoT systems that contain thousands of low-power and low-compute embedded devices

However, that does not mean that either protocol is inherently “better”. Specific use cases will determine which protocol is best for a project.

1. Architecture

The architecture of a protocol sets up the actors in the system, assigns them roles, and allows messaging between them. AMQP allows both the client/broker and client/server architectures. MQTT only allows client/broker architecture. A broker is different from a server in that it acts as a mediator between two parties and, unlike a server, it does not serve a single client.

2. Messaging scenarios

MQTT supports a single messaging strategy, publish-subscribe (pub/sub). Pub/sub messaging uses the concept of “topics.” A topic is a string used by the MQTT broker to filter messages.

A node that “subscribes” to a topic starts receiving all messages “published” by other nodes with that topic. Alternatively, AMQP supports many different messaging scenarios, including publish-subscribe messaging. Some of the other patterns are publish-consume, lifetime, as-long-as-connected, nobody-is-using-this-queue. A more extensive set of messaging strategies allows AMQP developers to tailor their applications according to their requirements.

AMQP publish-consume messaging. (Source)

3. Framing

Framing specifies the structure of a message in a messaging protocol. It lays out the positions and sizes of different sections of a message. The following questions about framing help you select the suitable messaging protocol for your application:

• What is the size of your single data unit? Is it large?
• Would it need to be fragmented?
• What is the data flow pattern: stream-oriented or buffer-oriented?

MQTT’s maximum allowed data size is 256 MB, best suited for applications with a smaller amount of data per message. It also has a smaller header size compared with AMQP. MQTT doesn’t fragment data over multiple packets. Given its stream-oriented data flow, MQTT messages are effectively ephemeral. MQTT actively routes messages between simultaneously connected publishers and subscribers. If there is no subscriber, the broker discards the message. This arrangement points to applications optimized for smaller functions that don’t need many options.

AMQP has an undefined message size which means that you can accommodate your desired amount of data in each packet. AMQP also allows you to fragment the data over multiple packets. Lastly, the larger header size provides more messaging options.

4. Transactions

Transactions are set sequences of message exchanges between two communicating nodes. Examples include a handshake, authentication, data transfer, and acknowledgment. Such transactions are common for all communication protocols and depend upon the protocol’s options.

AMQP provides a larger set of semantics (methods) to carry out various transaction types. This design follows the usability scenarios and possibilities of AMQP. AMQP supports the following methods: Consume, Deliver, Publish, Get, Select, Ack, Delete, Nack, Recover, Reject, Open, and Close.

For MQTT, there are only six semantic options: Connect, Disconnect, Publish, Subscribe, Unsubscribe, and Close. As mentioned above, everything in MQTT revolves around publishing or subscribing to a topic.

5. Security

Security is a critical requirement in IoT systems. Many mission-critical environments or environments involving users’ safety use IoT systems. Any breach of security can be catastrophic to the project or its stakeholders.

MQTT uses a TLS profile to authorize connections between clients and brokers. It also protects the resources for the identified topic names. Client authentication uses access tokens.

Example of MQTT communication with TLS encryption. (Source)

AMQP has richer security features than MQTT’s. That is one of the reasons for its use in a corporate environment where security requirements are critical. The AMQP security standard explicitly facilitates the integration of TLS and SASL, supports their extensions (e.g., client authentication, data encryption), and allows for separate negotiation and policies for both security mechanisms.

In an MQTT network, a network-level firewall secures the broker. At the application level, we can use encryption to secure MQTT packets. Any further improvement requires updating the protocol and broker. Available brokers, typically, don’t allow for such modifications. In such a case, it’s necessary to deploy your broker and customize it.

6. Reliability

In terms of reliability, both protocols have comparable offerings. However, AMQP has only two levels of Quality of Service (QoS) while MQTT has three levels of (QoS) for reliable message delivery. QoS0 is the lowest reliability level and is a best-effort delivery. QoS1 is the next higher level of reliability; however, it could cause the duplication of messages. QoS2 is the highest reliability level in MQTT. MQTT can also guarantee the delivery of a message in case of a disconnection.

7. Extensibility

The AMQP protocol embraces extensibility. It facilitates new extensions to itself. Because it is a layered protocol, changes in one part do not affect the other parts.

On the other hand, the specification constraints MQTT’s extensibility, as per the specification. Any change in the protocols requires re-writing the protocol.

8. Message Discovery

Namespaces are an effective way to find messages. AMQP provides several approaches to identify the messages: spaces like nodes and queues, consumers “choosing” how to find messages, consumers sharing queues, receiving copies of messages, or removing messages from queues. Additionally, the meta-data in AMQP allows designers to implement new ways for messages identification.

MQTT provides only a hierarchical “topic” namespace. Every implementation follows the topic convention.

9. Implementation

While ease-of-use is somewhat subject, in general, MQTT is considered slightly easier to implement than AMQP. This is because MQTT is a simpler protocol with fewer options to tweak and decisions to make.

Additionally, MQTT libraries are available in multiple programming languages like Java, JavaScript, C/C++, and Python. Similarly, brokers are available in the public domain. The availability of such support minimizes development cost and shortens development time.

Both AQMP and MQTT have plenty of online support available in sample implementations, documentation, and communities.

10. Compatibility

Messaging protocol deployments are for the long term. Being the communication mechanism, their ability to remain compatible with an infrastructure upgrade is essential. An inflexible messaging protocol is incompatible with infrastructure upgrades and necessitates changes.

AMQP is a comprehensive messaging protocol that provides options for different infrastructure scenarios. It has fine-grain control on features like redirection and load balancing. These features are helpful if there is a change in the network configuration. or upgrade. On the other hand, MQTT is not flexible enough to account for future infrastructure changes as easily as AQMP.

AMQP vs. MQTT Use Cases

Now, let’s take a look at some of the applications that implement these IoT messaging protocols.

AMQP

AMQP is prevalent in applications where messaging is more than sensor data or alerts sharing.

In this case, data can take a more complex form, and reliability and systems interoperability is more important. Therefore, it is widely used in finance, defense, telecommunications, and manufacturing at enterprise-level projects. Examples of use cases are messaging inside business systems of different types, messaging between clouds of various kinds, and messaging across datacenter boundaries.

According to AMQP, JPMorgan, Google, NASA, RedHat, Mozilla, AT&T, IBM, and OpenStack are just a few of the companies that deploy AMQP for their projects.

MQTT

MQTT is generally used in scenarios involving low-bandwidth, high-latency networks, and low-compute devices. It is a lower footprint and efficient protocol and works well in these situations.

Therefore, it is prevalent in the IoT world, especially in automotive, smart homes, manufacturing, and telecommunications. This is also why all major cloud platforms support it (Microsoft Azure, Amazon Web Services, IBM Watson).

Conclusion

While the task of selecting a messaging protocol may seem daunting, it becomes easier once you understand the tradeoffs. Certain project types lend themselves to a particular protocol, making your selection process easier.

When it comes to these two messaging protocols, MQTT is a better choice for sensor networks, low-compute devices, a low-bandwidth network, and need a basic level of security. On the other hand, for corporate business systems, reliable networks, disparate messaging needs, and stringent security requirements, AMQP is a better choice.

Content produced by Inbound Square