What is MQTT?
MQTT is an open protocol, standardized by OASIS and ISO (ISO/IEC 20922:2016). It is used for data exchange with constrained devices in the field. It keeps network bandwidth at a minimum level and handles unreliable networks without complex error handling and a huge implementation effort. It was made for keeping a steady line to your devices at a minimal cost supporting real push notifications and near real-time communication.
Connect thousands of devices to the business, sending instant updates and broadcast push notifications is where MQTT truly excels. It’s made for devices and is lightweight on the wire, enabling low-cost device communication that scales with the business.
MQTT is based on the publish/subscribe paradigm. This enables easy broadcasting of messages from one publisher to many subscribers. Messages from a huge amount of publishers to a few subscribers are covered as well. Additionally, the connection is built-up from the client side, which makes a bidirectional communication possible without NAT translation issues.
Two aspects of MQTT:
Client
MQTT client includes publisher or subscribers. An MQTT client is any device from a microcontroller up to a full-fledged server, that has an MQTT library running and is connecting to an MQTT broker over any kind of network. MQTT client libraries are available for a huge variety of programming languages, for example, Android, Arduino, C, C++, C#, Ruby, Go, iOS, Java, JavaScript,.NET.
Broker
MQTT broker is the heart of any publish/subscribe protocol. A broker can handle up to thousands of concurrently connected MQTT clients. The broker is primarily responsible for receiving all messages, filtering them, decide who is interested in it and then sending the message to all subscribed clients. It also holds the session of all persisted clients including subscriptions and missed messages. Another responsibility of the broker is the authentication and authorization of clients.
How MQTT Works?
The MQTT protocol is based on top of TCP/IP and both client and broker need to have a TCP/IP stack.
The protocol uses a publish/subscribe architecture in contrast to HTTP with its request/response paradigm. Publish/Subscribe is event-driven and enables messages to be pushed to clients. The central communication point is the MQTT broker, it is in charge of dispatching all messages between the senders and the rightful receivers. Each client that publishes a message to the broker, includes a topic into the message. The topic is the routing information for the broker.
Each client that wants to receive messages subscribes to a certain topic and the broker delivers all messages with the matching topic to the client. Therefore the clients don’t have to know each other, they only communicate over the topic. This architecture enables highly scalable solutions without dependencies between the data producers and the data consumers.
Difference from other protocols
The difference to HTTP is that a client doesn’t have to pull the information it needs, but the broker pushes the information to the client, in the case, there is something new. Therefore each MQTT client has a permanently open TCP connection to the broker. If this connection is interrupted by any circumstances, the MQTT broker can buffer all messages and send them to the client when it is back online.
The central concept in MQTT to dispatch messages are topics. A topic is a simple string that can have more hierarchy levels, which are separated by a slash. A sample topic for sending temperature data of the living room could be house/living-room/temperature. On one hand, the client can subscribe to the exact topic or on the other hand use a wildcard.
The subscription to house/+/temperature would result in all message sent to the previously mention topic house/living-room/temperature as well as any topic with an arbitrary value in the place of the living room, for example, house/kitchen/temperature. The plus sign is a single level wild card and only allows arbitrary values for one hierarchy. If you need to subscribe to more than one level, for example to the entire subtree, there is also a multilevel wildcard (#). It allows subscribing to all underlying hierarchy levels. For example, house/# is subscribing to all topics beginning with the house.
Options while making connection through MQTT
ClientId
It is an identifier of each MQTT client connecting to an MQTT broker. It should be unique per broker. The broker uses it for identifying the client and the current state of the client. If you don’t need a state to be held by the broker, in MQTT 3.1.1 (current standard) it is also possible to send an empty ClientId, which results in a connection without any state. A condition is that clean session is true, otherwise, the connection will be rejected.
Clean Session
The clean session flag indicates the broker, whether the client wants to establish a persistent session or not. A persistent session (CleanSession is false) means, that the broker will store all subscriptions for the client and also all missed messages when subscribing with Quality of Service (QoS) 1 or 2. If a clean session is set to true, the broker won’t store anything for the client and will also purge all information from a previous persistent session.
Username/Password
MQTT allows sending a username and password for authenticating the client and also authorization. However, the password is sent in plaintext, if it isn’t encrypted or hashed by the implementation or TLS is used underneath. Use of username and password is highly recommended together with a secure transport of it.
Will Message
The will message is part of the last will and testament feature of MQTT. It allows notifying other clients when a client disconnects ungracefully. A connecting client will provide his will in form of an MQTT message and topic in the CONNECT message. If this client gets disconnected ungracefully, the broker sends this message on behalf of the client.
Keep-Alive
The keep alive is a time interval, the clients commit to by sending regular PING Request messages to the broker. The broker response with PING Response and this mechanism will allow both sides to determine if the other one is still alive and reachable.