MQTT Protocol | MQTT in Depth | MQTT vs CoAP

mqtt protocol

In this article, We discuss MQTT Protocol and i am trying to explain MQTT in Depth with MQTT vs CoAP Protocol.

IoT Data Protocols

Some Popular Internet of Things Protocols is – MQTT, CoAP and AMQP.

We Explain MQTT in depth here and if you are interested in AMQP and CoAP Protocol. Please visit given below links.

What is MQTT Protocol?

MQTT used to stand for MQ Telemetry Transport, but is today referred to simply as MQTT and is no longer an acronym. It is an extremely simple and lightweight Publish/Subscribe messaging protocol invented at IBM and Arcom (now Eurotech) to connect restricted devices in low bandwidth, high-latency or unreliable networks.

MQTT was originally designed to connect sensor nodes over communication networks that are unreliable or high-latency, or both.

As an example, MQTT has long been and still is used for monitoring oil and gas pipeline operations. Pipelines don’t always run through areas with good connectivity, requiring a communication protocol that can cope with such an environment. Seensor nodes are often quite constrained in terms of resources and abilities, running on battery power and forced to limit energy consumption. They might also rely on satellite communication links with limited bandwidth and performance. MQTT was designed for such environments.

It’s pretty clear today that MQTT is not limited to its original oil and gas use case, but has much broader applications in M2M, mobile and IoT verticals. Facebook uses MQTT in their Facebook Messenger. That seems very different to monitoring a pipeline first, but there are many similar technical constraints, like a mobile device with limited power and rapid network connectivity changes.

To choose the right messaging technology, it is critical to know in what kind of environment the devices will be running and what their communication patterns will look like.

If your project shares some similarities with the uses cases just mentioned, with a Publish/Subscribe messaging pattern, or just the need for a Message Queue, read on! There are good chances MQTT is the right tool for the job.

MQTT in Depth

Quality of Service in MQTT Protocol

Quality of Service (QoS) is a rather broad topic in general. For MQTT though, QoS takes a simple form. It allows an application (= a client publishing or subscribing to a topic) to choose one of the following transport guarantees:

Fire and forget (QoS 0)

A client won’t receive any confirmation from the broker upon receipt. Likewise a message delivered to a client from the broker is not required to be acknowledged. This is the fastest way to publish and receive messages, but also the one where message loss is most likely to happen.

At least once (QoS 1)

A client will receive a confirmation message from the broker upon receipt. If the expected confirmation is not received within a certain time frame, the client has to retry the message. A message received by a client must be acknowledged on time as well, otherwise the broker will re-deliver the message.

Exactly once (QoS 2)

The first part of the QoS 2 flow is similar to QoS 1. A second flow ensures that sender and receiver (broker) agree on where the message stands. The point is to avoid duplicate routing, i.e. delivery to the subscribers downstream of the broker, as the broker can recognize duplicates itself. QoS 2 doesn’t necessarily imply that the publisher will only send the message once, it will still retry if it gets no acks from the broker.

The choice of QoS should be based on the network environment. A mobile app could use QoS 0 whenever it is connected to a reliable wireless connection and falling back to QoS 1 when connected to the mobile network.

Last Will Testament

This feature is unique among IoT messaging protocols. The Last Will Testament or short LWT lets a client provide a testament along with its credentials when connecting to the broker. If the client disconnects ungracefully at some point later (maybe because his power source died), it can let the broker deliver a message to other clients. (Comparable to a real testament that gets communicated to the bereaved). This LWT message has the same form as an ordinary message and gets routed via the same mechanics.

Such a simple LWT mechanism can become very handy if your application has to track some sort of presence status of the participating devices.

Clean Session

To understand what the clean session feature is about, we have to look at the MQTT session initiation. When a device connects to a MQTT broker for the first time it implicitly creates a new MQTT session. One part of that session consists of state stored on the broker, and the other part of the session is state stored on the client.

Session state can be bound to the lifetime of the TCP connection, but it doesn’t have to be. The state on the broker and the client can also be persisted.

What is in the Session State? Let’s have a look what the MQTT specification says about what should be in the server state and the client state of a session:

The session state in the client consists of:

  • QoS 1 and QoS 2 messages which have been sent to the Server, but have not been completely acknowledged.
  • QoS 2 messages which have been received from the Server, but have not been completely acknowledged.

The session state in the server consists of:

  • The existence of a Session, even if the rest of the Session state is empty.
  • The Client’s subscriptions.
  • QoS 1 and QoS 2 messages which have been sent to the Client, but have not been completely acknowledged.
  • QoS 1 & QoS 2 messages pending transmission to the Client.
  • QoS2 messages which have been received from the Client, but have not been completely acknowledged.
  • Optionally, QoS 0 messages pending transmission to the Client.

In conclusion, one of the benefits of MQTT and its session concept, is that sessions can survive re-connects. When connectivity is very expensive, limited, or rapidly changing a device will not be connected all the time. While offline, the broker still keeps the session around and accumulates all messages that match the device’s subscriptions. As soon as the client reconnects all the outstanding messages will be delivered.

Retained Messages

Publishers can mark any message they send as ‘to be retained’. There can only be one retained message per topic, and any new ‘retained’ message by any publisher to that topic will replace the current one. Retained messages are only delivered when a client subscribes to a topic. The most common use case for this is to push some kind of last known message (or sensor value) to new subscribers. The broker has to store all retained messages in a database, as the retained message will not expire.

Retained messages are not to be confused with ‘offline’ messages, i.e. the QoS 1 and 2 messages that the broker has to store for any offline subscribers.

This feature paired with the LWT feature enable to implement a simple presence notification system using plain MQTT.

Recommended: STOMP – Simple/Streaming Text Oriented Messaging Protocol

Message Queue in MQTT Protocol

A Message Queueing system receives, stores and forwards messages. Those actions tend to vary heavily from one implementation or messaging protocol to another.

The core component of a queueing system is, of course, a data structure called queue. The underlying theory of a queueing system is quite complex, so let’s assume for now that a queue is some sort of a database. While most general purpose databases have powerful query capabilities such as the SQL query language, a queue in it’s most basic form only knows two operations, push and pop.

The Push operation inserts a new element to the queue, the Pop operation reads the oldest element from the queue and deletes it afterwards. This is also called the FIFO model, first in first out. In certain cases the Pop operation should always read the newest element instead of the oldest. Such a datastructure is called a stack, while the model is called LIFO, last in first out.

A message queueing system could implement more advanced queuing operations like message priority support or ways to automatically delete old messages.

A message queue is a perfect addition to the Publish/Subscribe pattern because it backs the decoupling principle. For this reason most Publish/Subscribe protocol implementations rely on a message broker that also implements a message queuing system.


Publish/Subscribe is a messaging pattern that aims to decouple the sending (Publisher) and receiving (Subscriber) party. A real world example could be a sport mobile app that shows you up-to-date information of a particular football game you’re interested in. In this case you are the subscriber, as you express interest in this specific game. On the other side sits the publisher, which is an online reporter that feeds a system with the actual match data. This system, which is often referred as the message broker brings the two parties together by sending the new data to all interested subscribers.

The Publish/Subscribe messaging pattern brings many benefits:

  • Implement the publisher and subscriber parties independently from each other
  • Publishers and Subscribers don’t require to know each other
  • One Subscriber could receive from many different Publishers
  • One Publisher could send data to many different Subscribers

The benefits can be sumarized to Loose Coupling, the decoupling of publisher and subscriber, as well as Scalability through the parallel nature of the publisher and subscriber components.

Many standardized messaging protocols that implement a Publish/Subscribe pattern exist. In the area of application level protocols the most interesting ones are:

  • AMQP, Advanced Message Queueing Protocol
  • MQTT, MQ Telemetry Transport
  • JMS, Java Messaging Service
  • XMPP, Extensible Messaging and Presence Protocol

A publish/subscribe messaging protocol is only as useful as its message broker implementations.


MQTT 5 | MQTT 5.0 | MQTT Protocol 5

The MQTT version 5 was released last year and a lot of people have been blogging and tweeting and talking about the merits of this protocol update. And there are tons of improvements! Here’s a list of some of them:

  • Metadata via user properties: the ability to add extra information which can be inspected without having to parse and inspect the payload.
  • Negative acknowledgements which makes it a lot easier for a client to understand what’s happening.
  • Request/Response interactions.
  • Provisioning features where brokers can tell clients to (re)connect to other broker instances.
  • Fine grained retained messages handling.
  • Differentiate received messages for which the subscriptions overlap using subscription identifiers.
  • Enhanced authentication mechanism.
  • Shared subscriptions to easily handle massive fan-in scenarios.
  • Topic aliases which saves band-with when publishing messages.
  • Use Message expiration to prevent clients from receiving stale/irrelevant information.

All above mention features are sorely needed. Some more than others. Negative acknowledgements allow for much easier debugging cycles when trying to understand why some client can’t connect, publish or subscribe to a specific topic by telling the client what actually happened. Shared subscriptions are needed to overcome the limitations of a single subscriber receiving more messages than it can handle. Topic aliases are great for those clients where the up-link is expensive and saving as many bits as possible is paramount.

Is it still lightweight?

MQTT 5 is same as MQTT 3.1.1. The only new packet is the AUTH packet which can be used to support SASL type authentication schemes. The rest flow as usual and the only case where more packets are flowing compared to MQTT 3.1.1 is to support the new features such as negative acknowledgements where earlier the client would just be disconnected.

The biggest change on the protocol level is the addition of properties which (for most) packets are optional. Properties are a list of key-value pairs which is used to support many of the new features introduced in the protocol. For instance topic aliases, message expiration intervals, enhanced authentication methods and data, and metadata (user properties) are all implemented as specific properties on the various packets.

On the wire this means that packets can contain extra optional data that only has to be parsed if it is there. The additional extra computational overhead is therefore to check if optional data is present or not, and if so, to parse it.

The extra work the parser has to do is extremely little and would not be noticeable on small scale MQTT deployments and even on large scale deployments it would not be expected to have any significant impact.

So MQTT 5 basically provides a lot of new features while making sure the computation and band-with cost is effectively zero if they aren’t used!

Broker and client library perspective

Compliant client libraries and brokers have to implement all these new features in all their glory and complexity. Fortunately most people don’t have to worry about this as a bunch of great MQTT 5 compliant client libraries are already in development! For instance the Eclipse Paho C, Go, and Java clients are well under way and the highly popular Mosquitto broker has also announced MQTT 5 support by August 2018.

MQTT Servers/Brokers

Apache ActiveMQ

Details of “classic” ActiveMQ’s support for MQTT are available here.

Apache ActiveMQ Artemis

The “next generation” of ActiveMQ, Artemis is a multi protocol messaging broker that supports MQTT.

Bevywise MQTT Broker

MQTTRoute is a highly secure, high performance broker. The MQTT Broker is written in C & Python and works with all standard MQTT Clients. Bevywise MQTT Broker has a FREE and affordable premium version. MQTTRoute can be customized to write data to any data store using standard connectors or custom implementations. Try the publicly hosted MQTTRoute


Emitter is clustered and open-source MQTT broker, written entirely in Go. It proposes several additional features on top of a traditional MQTT broker, as it includes custom per-topic security and shared-nothing scalable architecture which helps you avoid single points of failure. Full source-code available on GitHub.


emqttd is a distributed, massively scalable, highly extensible MQTT message broker written in Erlang/OTP. / @emqtt

emqttd is fully open source and licensed under the Apache Version 2.0. EMQ implements both MQTT V3.1 and V3.1.1 protocol specifications, and supports MQTT-SN, CoAP, WebSocket, STOMP and SockJS at the same time. emqttd provides a scalable, reliable, enterprise-grade MQTT message Hub for IoT, M2M, Smart Hardware and Mobile Messaging Applications. The 1.0 release of the emqttd broker has scaled to 1.3 million concurrent MQTT connections on a 12 Core, 32G CentOS server.

Eurotech Everywhere Device Cloud

Eurotech Everywhere Device Cloud is a cloud-based service provided by Eurotech

You may like also: How To Create Secure MQTT Broker


flespi is a public and free cloud-based MQTT broker service with declared 3.1, 3.1.1, 5.0 protocols compliance. High-volume targeted architecture, isolated MQTT namespace, WebSockets/SSL support, configurable ACL, commercial and free SLA, managed by HTTP REST API.


HBMQTT is an open-source implementation of MQTT broker and client. It uses Python 3.4+ asyncio library for providing a mono-threaded, non-blocking implementation of the protocol.


HiveMQ is a MQTT broker which was built from the ground up with maximum scalability and enterprise-ready security in mind. It comes with native web socket support and an open source plugin SDK to extend its functionality or integrate it with other components. A public test server is also available (more information).


Jmqtt is a MQTT broker which implemented by java and netty,support persistence and cluster.

IBM Integration Bus

IBM Integration Bus V9 has Telemetry feature built-in as optional licensed feature. IBM WebSphere MessageBroker V7 & V8 also include it as optionally licensed feature.

Really Small Message Broker 75KB MQTT broker runtime free download as binaries from IBM alphaWorks, RSMB is a C implementation of a tiny MQTT server suitable for development, embedded systems, concentrators or small to medium sized deployments. It provides complete MQTT v3.1 support, bridging, and a C client API.

IBM MessageSight

IBM MessageSight is a DMZ secure MQTT appliance with hardware messaging acceleration for M2M and mobile applications requiring extreme volume, low latency, FIPS 140-2 and NSA Suite B security. Messaging provider for MQTT, HTML5 WebSockets, JMS. Includes C, Java, JavaScript, Apache Cordova/PhoneGap, ObjectiveC clients. Also connects/bridges IBM MQ, IBM Integration Bus, WebSphere MessageBroker.

IBM Websphere MQ Telemetry

The Telemetry MQTT feature is built-in optionally licensed feature in WebSphere MQ version 7.1 and above. It provides full MQTT v3.1 support, IBM MQ and JMS support. IBM WebSphere MQ Advanced includes the MQTT license at no charge. It ships with reference Java (MIDP and above), C and JavaScript (MQTT over WebSocket) clients.


JoramMQ is an offering by ScalAgent providing a message broker that fully supports MQTT 3.1, JMS 2.0, and AMQP 1.0. Interoperability between these standards is ensured by the message broker. MQTT can be used over TCP/IP, TLS (SSL), WebSocket, and secure WebSocket. JoramMQ is particularly appropriate for applications that need to scale with the number of MQTT clients while allowing the publishers to reliably transmit a large volume of messages with a low latency.

Litmus Automation Loop

Loop is a cloud based MQTT broker with scalability, high availability and security at core. Loop provides full MQTT 3.1 support and JMS connectivity. It can handle extremely large numbers of connected clients. On the other side it can be connected to any ERP, CRM and enterprise architecture with ESB or NoSQL databases for blazing fast data storage.


Moquette is a Java MQTT broker based on an eventing model with Netty.


As node.js MQTT broker can Mosca be plugged on top of Redis, AMQP, MQTT, or ZeroMQ.


Mosquitto is an Open Source MQTT server that implements the MQTT protocol versions 3.1 and 3.1.1. Mosquitto is lightweight and is suitable for use on all devices from low power single board computers to full servers.

A public, hosted test server is also available (more information). Read this – Setting up Authentication in Mosquitto MQTT Broker Cloud MQTT platform to build your IoT projects. It includes support for MQTT, MQTT-TLS, Web Interface and REST API for full HTTP+MQTT integration.


MQTTnet is a .NET library for MQTT based communication. It provides a MQTT client and a MQTT server (broker).


MqttWk is a Java MQTT broker based on NutzBoot + Netty + Redis + Kafka(Optional).The broker supports QoS 0, QoS 1 and QoS 2.It uses Netty for the protocol encoding and decoding part.Using NutzBoot to provide dependency injection and attribute configuration, using Redis to implement message caching and clustering, and using Kafka to implement message proxy.


RabbitMQ is an AMQP message broker – with an MQTT plugin (bundled in version 3.x onwards). A public test server is also available (more information).

RabbitMQ is the most widely deployed open source message broker software (sometimes called message-oriented middleware) that originally implemented the Advanced Message Queuing Protocol (AMQP) and has since been extended with a plug-in architecture to support Streaming Text Oriented Messaging Protocol (STOMP), Message Queuing Telemetry Transport (MQTT), and other protocols.

RabbitMQ is lightweight and easy to deploy on premises and in the cloud. It supports multiple messaging protocols. RabbitMQ can be deployed in distributed and federated configurations to meet high-scale, high-availability requirements.

The RabbitMQ server program is written in the Erlang programming language and is built on the Open Telecom Platform framework for clustering and failover. Client libraries to interface with the broker are available for all major programming languages. RabbitMQ runs on many operating systems and cloud environments, and provides a wide range of developer tools for most popular languages.


Solace Message Routers (available as hardware and software) are message brokers that support MQTT, JMS, and REST among other APIs, protocols and qualities of service for enterprise messaging, data collection and web/mobile streaming. They support very high connection counts and throughput with built-in buffering to handle bursty traffic, and offer enterprise-class monitoring, high availability and security.


SwiftMQ Universal Router is an enterprise message system with integrated micro services and realtime streaming analytics platform (SwiftMQ Streams, SwiftMQ Dashboard). It supports MQTT 3.1/3.1.1, AMQP 1.0/0.9.1, JMS 1.1 and is fully interoperable between these protocols. It has a built-in Dynamic Routing Architecture to build large Federated Router Networks and Clusters. SwiftMQ High Availability Router is the High and Continuous Availability version of SwiftMQ Universal Router with active replication and transparent client failover.

ThingScale IoT message broker

ThingScale IoT message broker is a fully-managed IoT messaging service provided by Sensinics,LLC. ThingScale provides a messaging system for IoT connected devices. The API is used to retrieve events, users, devices, sessions, and channels in JSON format. ThingScale supports TLS payload encryption, scheme-less and cyclic data sampling, and trigger-based notifications. A 30days trial license is offered free of charge. MQTT is the preferred messaging protocol.


VerneMQ is an enterprise ready, high-performance, distributed MQTT message broker. It scales horizontally and vertically on commodity hardware to support a high number of concurrent publishers and consumers while maintaining low and predictable latency and fault tolerance. VerneMQ plugins can be developed in Erlang, Elixir, Lua, and any programming language that can implement HTTP WebHooks. VerneMQ uses modern broadcast protocols and LevelDB for state replication in a cluster. VerneMQ is Open Source and Apache2 licensed.

Vert.x MQTT Broker

Vert.x MQTT Broker is an open-source implementation of MQTT server. It implements protocol versions 3.1.1 and 3.1, supports QoS 2, and uses OAuth2 for autentication. It uses vert.x as library for tcp managemnet, non-blocking / actor-model, clustering and auth plugin system.

Yunba is a backend cloud platform that provides real-time message dispatch service to mobile applications and devices and uses MQTT as a transport protocol, The services include bi-directional push for Instant-Messaging; real-time analyzing; real-time online monitoring.


Cassandana is an open source MQTT message broker which is entirely written in Java. This project began its life as a fork of Moquette , and later underwent some cleanup, optimization and adding extra features. Now it’s ready to work as an enterprise message broker. Features: MQTT compliant broker. Supports QoS 0, QoS 1 and QoS 2 TLS (SSL) Encryption PostgreSQL, MySQL and MongoDB Authentication and Authorization Supports HTTP REST API for Authentication and Authorization MQTT message archiver (Silo integrated in Cassandana) Easy configurable (YAML based) Supports WebSocket.

Server support

Server QoS 0 QoS 1 QoS 2 auth bridge $SYS SSL dynamic topics cluster websockets plugin system
2lemetry §
Jmqtt § § §
Apache ActiveMQ
Apache ActiveMQ Artemis
Bevywise IoT Platform rm
emitter §
IBM MessageSight §
Mongoose ? ? ? ? ? ? ? ? ?
moquette ? ? ? rm
mosca ? ? ? ?
mosquitto §
MQTT.js §
MqttWk ?
RabbitMQ ? ? ?
Software AG Universal Messaging rm
Solace §
Trafero Tstack
WebSphere MQ ? ? ?

=> Key: ✔ supported ✘ not supported ? unknown § see limitations rm roadmap (planned)


  • MQTT.js will accept connections with username and password supplied, but do not actually authenticate the connection
  • IBM MessageSight supports a High-Availability mode which provides the redundancy advantage of a cluster, but does not support any sort of load balancing for MQTT.
  • 2lemetry uses domains, where the first topic segment is the domain name. The $SYS topic space is under the domain (i.e. com.example/$SYS/#)
  • Solace does provide a proprietary bridge solution between brokers.
  • mosquitto clustering is achieved on backend level (redis, amqp, etc).
  • Software AG Universal Messaging provides Active/Active clustering (over a proprietary protocol) and bridging (over a proprietary protocol).

MQTT Client Libraries

Here you find a list of MQTT Client Libraries. so checkout this List.











  • hulaaki – An Elixir library (driver) for clients communicating with MQTT brokers(via the MQTT 3.1.1 protocol).
  • Exmqttc – Elixir wrapper for the emqttc library.




Javascript / Node.js



.NET / dotNET








  • MQTT Pack – Mosquitto library as a SWI-Prolog pack



  • qmqtt – MQTT Client for Qt

Shell Script

  • bish-bosh, supports bash, ash (including BusyBox), pdksh and mksh.



  • CocoaMQTT – An MQTT client for iOS and OS X written with Swift


MQTT Public Brokers


field value
port 1883 (TCP), 80 (WebSocket), 8883 (SSL), 443 (Secure WebSockets)
type flespi
info requires signup/username, information page, REST API, MQTT 5.0 compliant

field value
port 1883, 80 (WebSockets), 443(WebSockets+SSL)
type mosquitto
info web page, Xively statistics, topics and HTTP bridge

You may like also:  What is MQTT? | IoT Data Protocol | IoT Wireless Protocol

field value
port 1883, 8883 (SSL), 8884 (SSL), 80 (WebSockets)
type mosquitto
info web page, Xively statistics, topics and HTTP bridge

field value
port 1883, 8000 (WebSockets)
type HiveMQ
info information page, stastistics and dashboard

You may like also:How To Create Secure MQTT Broker

field value
address (Note: actual host varies, see dashboard)
port 18443, 28443 (SSL)
type mosquitto
info requires signup/username and password, pricing (free plan available), documentation

field value
port 1883 (MQTT), 8883 (MQTT+SSL), 8080 (WebSockets), 8880 (WebSockets+SSL)
type mosca
info Free – requires signup/username and password, documentation, includes mobile IoT app (iOS and Android)

field value
port 1883 (MQTT)
type mosquitto
info Free, it is mostly running for Swifitch project, but you can use it too for testing your IoT or whatever ;), it is running on Raspberry Pi profesional VPS.

field value
port 1883 (TCP), 8443 (WebSockets)
type Bevywise
info web page. Secure. Need to sign up to view your devices. Use MQTT Authentication in your devices to connect securely. Free trial with unsecure ports (see

field value
port 1883 (TCP), 8883 (TLS)
type ejabberd
info Free – no registration required, MQTT 5.0 compliant

You may like also:How To Create Secure MQTT Broker

field value
address (MQTT hostname varies, see dashboard)
port TCP, TLS, WS, WSS: varies per instance
type solace
info requires sign-up, free plan available (50 connections), getting started, docs

field value
port 1883 (TCP), 8883 (SSL), 443 (Web, REST and API interface)
type MyQtthub
info requires signup/username, information page, REST API

Note: none of these test mqtt public brokers carry any guarantee of service. Be sensible when using them and don’t break things for others! 🙂

These MQTT public brokers are useful only for testing and prototyping. If you used for your project please read this article. How To Create Secure MQTT Broker

COAP vs MQTT | Difference between COAP and MQTT Protocol

COAP and MQTT both are most popular Communication protocol in Internet of things.

What is COAP ?

Constrained Application Protocol (CoAP), on the other hand, is a client-server protocol that, unlike MQTT, is not yet standardized. With CoAP, a client node can command another node by sending a CoAP packet. The CoAP server will interpret it, extract the payload, and decide what to do depending on its logic. The server does not necessarily have to acknowledge the request.

Read more … CoAP Protocol- Constrained Application Protocol

Both MQTT and CoAP:

  • Are open standards
  • Are better suited to constrained environments than HTTP
  • Provide mechanisms for asynchronous communication
  • Run on IP
  • Have a range of implementations

mqtt vs coap

Following table compares various features of COAP vs MQTT and tabulates difference between CoAP and MQTT protocols.

Features CoAP MQTT
Full Form Constrained Application Protocol Message Queue Telemetry Transport
Model used for communication Request-Response, Publish-Subscribe Publish-Subscribe
RESTful Yes No
Transport layer Preferably UDP, TCP can also be used. Preferably TCP, UDP can also be used (MQTT-S).
Header Size 4 Bytes 2 Bytes
Number of message types used 4 16
Messaging Asynchronous & Synchronous Asynchronous
Application Reliability 2 Levels 3 Levels
Security IPSEC or DTLS Not defined in the standard
Intermediaries YES YES (MQTT-S)
LLN Suitability (thousand nodes) Excellent Fair
Application success stories Utility Field Area Networks Extending enterprise messaging into IoT applications


MQTT and CoAP are both useful as IoT protocols, but have fundamental differences.

MQTT Protocol is a many-to-many communication protocol for passing messages between multiple clients through a central broker. It decouples producer and consumer by letting clients publish and having the broker decide where to route and copy messages. While MQTT has some support for persistence, it does best as a communications bus for live data.

CoAP is, primarily, a one-to-one protocol for transferring state information between client and server. While it has support for observing resources, CoAP is best suited to a state transfer model, not purely event based.

MQTT clients make a long-lived outgoing TCP connection to a broker. This usually presents no problem for devices behind NAT. CoAP clients and servers both send and receive UDP packets. In NAT environments, tunnelling or port forwarding can be used to allow CoAP, or devices may first initiate a connection to the head-end as in LWM2M.

MQTT provides no support for labelling messages with types or other metadata to help clients understand it. MQTT messages can be used for any purpose, but all clients must know the message formats up-front to allow communication. CoAP, conversely, provides inbuilt support for content negotiation and discovery allowing devices to probe each other to find ways of exchanging data.

Both protocols have pros and cons, choosing the right one depends on your application.

MQTT Protocol FAQs

What is MQTT Protocol ?

MQTT is a lightweight publish/subscribe messaging protocol designed for M2M (machine to machine) telemetry in low bandwidth environments. It works on top of the TCP/IP protocol and it needs a central MQTT Broker to collect and send data from and to publishing and subscribing machines.

What is a MQTT broker?

MQTT Broker is a central server or middle-ware which act as an interface between publisher & subscriber and used to collect the data from the publisher device and send it to the subscribers device. A device wants to send data to the broker, it is called a publisher and a device wants to receive data from the broker, it is called as subscriber

Recommended: How To Create Secure MQTT Broker

Why MQTT Protocol is used in IoT?

MQTT is a lightweight, machine to machine communications protocol which helps the small IoT device in low bandwidth or network to send or publish data to the MQTT Broker or server. MQTT protocol provides faster response and throughput, lower battery and bandwidth usage, and work in low or poor network connectivity. It also provides secure communication via TLS/SSL, edge level authentication and QoS to manage data traffic to reduce packet loss and latency on the network. This advantages make MQTT well-suited for “internet of things” applications

Does MQTT require Internet?

Internet is not needed when you connect the MQTT broker and your client or device under the same network. But if you want to connect a device from a different network, you must host the MQTT Broker in cloud and connect your device via internet using Public Ip address. We recommend hosting the Broker securely on the cloud for controlling devices from anywhere.

Is MQTT secure?

Yes, MQTT Broker is built with TLS/SSL and Edge device authentication. TLS/SSL which provides a secure mechanism and data encryption between device & MQTT broker and edge device authentication will help the edge device to connect with username and password for secure data transfer.

Recommended: Setting up Authentication in Mosquitto MQTT Broker

Does MQTT Broker use TCP or UDP?

MQTT Broker use TCP/IP protocol to establish connection to client or device. However, for devices which are connected under UDP or device which are using zigbee or bluetooth protocol can be connected to the Broker via MQTT-SN Gateway.

What port does MQTT Protocol use?

MQTT has two types of communication methodology. TCP and Websocket. For TCP Internet Assigned Numbers Authority (IANA) reserved TCP/IP port ‘1883’ for a unencrypted and TCP/IP port ‘8883’ for TLS/SSL communication. You can use any flexible port for the MQTT over WebSocket.

Is MQTT Broker store data?

The specification does not mandate it. But the brokers need to store data as the manager application needs to use the data. Bevywise MQTT Broker store mqtt data in database like SQLite[default], MySQL, Elastic search and Mongo DB. Users can also store the data to any database using Custom implementation.

How can I view the connected device and its data in MQTT Broker?

Users can view the all connected device and its published data in MQTT Broker user interface and dashboard. MQTT Broker also has an individual web view for each active and inactive devices. Users can view the status of each devices, Broker uptime, Error log, add authentication credentials [username and password], active and inactive topics and also download Client librairies from user interface. MQTT Broker user interface runs in 8080 port and users can access via “http://< server ip address or localhost >:8080”

Does MQTT Route has Rule based automation?

Yes, MQTTRoute has a built-in rule engine which user an create rules or alert based on published messages. Rule engine help the users to send alert messages or forward published message to the subscriber when the data from a sensor crosses a certain threshold or range.

How can I build my IOT application over MQTT Broker ?

It is not advisable to build your IOT application via MQTT. You have to integrate using REST API. With this user can integrate their web application and get details about connected devices, authentication details etc by sending API request to MQTT Broker and the MQTTBroker send back data based on the API request or call.

Can I integrate MQTT Broker to my data visualization tool?

Yes, you can integrate MQTT Broker to your data visualization tool via Custom Implementation. Through custom implementation you can write your algorithm or code and push the data to your data visualization tool.

Is MQTT Broker can be hosted in containers?

Yes, MQTT Broker can be hosted in Docker containers.


Thanks for reading. If you like this post probably you might like my next ones, so please support me by subscribing my blog.


Hi, I'm Harshvardhan Mishra. Tech enthusiast and IT professional with a B.Tech in IT, PG Diploma in IoT from CDAC, and 6 years of industry experience. Founder of HVM Smart Solutions, blending technology for real-world solutions. As a passionate technical author, I simplify complex concepts for diverse audiences. Let's connect and explore the tech world together! If you want to help support me on my journey, consider sharing my articles, or Buy me a Coffee! Thank you for reading my blog! Happy learning! Linkedin

2 thoughts on “MQTT Protocol | MQTT in Depth | MQTT vs CoAP

Leave a Reply

Your email address will not be published. Required fields are marked *

Back To Top