Designing MQTT Over AMQP

Let’s think about what we can consider some weaknesses of the MQTT protocol.

• It provides native publish/subscribe pattern only; Using request/reply is quite cumbersome with “correlation injection” inside topics and payload messages.
• It doesn’t provide flow control.
• It doesn’t have metadata information inside messages (i.e. content type).
• It’s fully broker-centric.

But there are some unique features that we have to consider as strengths for this protocol as well.

• Retained messages (also known as “last well known” messages).
• Last will and testament (LWT).
• Session handling.

Now, let’s think about the main features that fill the gap for the MQTT protocol provided by AMQP:

• Native support for both publish/subscribe and request/reply patterns (correlation for free).
• Flow control at different levels (with max window size and message credits).
• A full type system and metadata information on each message.
• Peer-to-peer model (the broker is just a peer).

But it lacks those key MQTT features! So, how much greater could be AMQP be if it had them?

Under the open source EnMasse project, I have been working on a design (so a kind of “specification”) for having retained messages, last will and testament, and session handling over AMQP. At the same time, I have been developing an MQTT “gateway” in order to allow remote MQTT clients to connect to an AMQP-based “Message as a Service” like EnMasse.

Having such a design means that not only can an MQTT client leverage retained messages after subscribing to a topic, sending its LWT over the connection or receiving messages for a topic when it was offline; it means having the above features for native AMQP clients as well.

Each feature is made by a well-defined AMQP message using specific subjects, annotations, and payloads in order to bring all MQTT-related information, like retained flags, will QoSes, will topics, and so on, but using AMQP semantics.

This sort of “specification” doesn’t force to use a specific implementation; the EnMasse project leverages on the Qpid Dispatch Router for connections and Apache Artemis brokers where a state is needed (but other implementations could use something different, like a simple file system or a database). Of course, some additional services are needed in order to handle LWTs and subscriptions (we just called them “Will Service” and “Subscription Service”).

If you are so curious and want to give some feedback , you can find all the open source stuff on GitHub in the MQTT over AMQP documentation section.