Understanding MQTT Clients and Brokers

In the previous issue, we introduced the publish and subscribe framework of MQTT:

MQTT Publish and Subscribe Architecture

The two most important roles are MQTT clients and MQTT brokers (intermediaries). Let’s quickly review these two core components:

• The publish/subscribe model decouples the client responsible for sending messages (the publisher) from the client responsible for receiving messages (the subscriber).

• MQTT uses message topics to determine which client (subscriber) should receive the messages. A topic is a hierarchical string used to filter and route messages.

Regarding these core roles, I believe a metaphor can illustrate this. It is similar to a real estate agent; for them, whether you are a homeowner or a buyer/renter, you are all considered their clients.

For buyers, you can only receive the information published by homeowners if you subscribe to the corresponding topics (based on your financial capacity for the relevant property information). Of course, after going through the real estate agent, the information will be filtered according to your needs before being sent to you.

MQTT Client

In the Internet of Things, an MQTT client typically refers to both publishers and subscribers. The publisher is the client that sends messages, while the subscriber is the client that receives messages. However, an MQTT client can also act as both a publisher and a subscriber.An MQTT client can be any device, from tiny microcontrollers to large servers, as long as it runs an MQTT library and connects to an MQTT broker over the network.MQTT client libraries are software modules or packages that implement the MQTT protocol and provide an MQTT communication interface for devices or applications. These libraries make it easier to add MQTT support to applications or devices without having to implement the protocol from scratch.

MQTT client libraries are available for various programming languages and platforms, such as Android, Arduino, C, C++, C#, Go, iOS, Java, JavaScript, .NET, etc. You can find a complete list of all available libraries on the MQTT wiki. We will share the corresponding libraries and platforms later, so stay tuned.

An MQTT client can be a typical computer used for testing purposes, running a graphical MQTT client. Any device that uses the TCP/IP network protocol and has software that implements MQTT client functionality can be referred to as an MQTT client. MQTT is designed to work over the TCP/IP protocol, so any device that uses TCP/IP and implements the MQTT protocol can be an MQTT client. The implementation of the MQTT protocol in clients is straightforward, making it very suitable for small devices.

MQTT Broker

An MQTT broker is the central hub in a publish/subscribe messaging system, receiving messages from publishers and distributing them to subscribers. It plays a critical role in managing the flow of communication between MQTT clients and ensuring reliable message delivery.The functions of an MQTT broker include:

• Handling a large number of concurrent connections: Depending on the implementation, the broker can handle millions of concurrent MQTT client connections. It establishes bridges between different devices, networks, and software systems, enabling them to communicate.

• Message filtering and routing: The broker filters messages based on subscribed topics and determines which clients should receive those messages.

• Session management: The broker maintains session data for all connected clients, including subscriptions and lost messages, for clients with persistent sessions.

• Authentication and authorization: The broker is responsible for authenticating and authorizing clients based on credentials provided by the clients. The broker is scalable, allowing for custom authentication, authorization, and integration with backend systems. In addition to authentication and authorization, the broker may also provide other security features, such as message transmission encryption and access control lists.

• Scalability, integration, and monitoring: An MQTT broker must be scalable to handle a large number of messages and clients, capable of integrating into backend systems, and easy to monitor while having fault tolerance. To meet these requirements, an MQTT broker must use state-of-the-art event-driven networking techniques, open extensibility systems, and standard monitoring providers. The broker can also provide advanced features for managing and monitoring the MQTT system, such as message filtering, message persistence, and real-time analytics.

Additionally, some MQTT brokers support clustering, allowing multiple broker instances to work together to handle a large number of clients and messages.

How to establish communication between MQTT clients and MQTT brokers?

The MQTT protocol has a key feature of efficient and lightweight message exchange between IoT devices. The foundation of this communication is the MQTT connection, which allows devices to exchange data securely and reliably with the MQTT broker. In this section, we will explore the process of establishing an MQTT connection and the various parameters involved. By understanding how MQTT connections work, you can optimize your IoT deployments for better performance, security, and scalability.

The MQTT protocol is based on TCP/IP, which means that both the client and the broker must have a TCP/IP stack.

MQTT connections are always made between the client and the broker server, and clients never connect directly to each other. To initiate a connection, the client sends a CONNECT message to the broker server, which replies with a CONNACK message and a status code. Once the connection is established, the broker keeps the connection open until the client sends a disconnect command or the connection is interrupted.

This section will explore the process of establishing an MQTT connection through NAT, as well as how MQTT clients initiate connections by sending CONNECT messages to the broker. We will delve into the MQTT CONNECT command message and highlight some important options, including ClientId, Clean Session, Username/Password, Will Message, and Keep Alive.

Additionally, we will discuss the broker’s response to the CONNECT message, which includes two data items in the CONNACK message: the session present flag and the connection return code.

In many cases, MQTT clients are located behind routers that use Network Address Translation (NAT) to convert private network addresses (such as 192.168.x.x or 10.0.x.x) to public addresses. As mentioned earlier, MQTT clients initiate connections by sending CONNECT messages to the broker. Since the broker has a public address and keeps the connection open after the initial CONNECT for bidirectional message sending and receiving, MQTT clients behind NAT routers do not face any difficulties.

For those unfamiliar, NAT is a common networking technology that allows devices in a private network to access the internet through a single public IP address. NAT works by translating the IP addresses of devices in the private network to the router’s public IP address and vice versa.

In the case of MQTT, even if clients are behind NAT routers, they can still communicate with the MQTT broker because the broker has a public IP address and can connect with clients through NAT. However, NAT may lead to some potential issues, such as the need to configure port forwarding or open firewall ports to allow incoming traffic to reach the MQTT broker. Additionally, some NAT implementations may limit the number of connections that can be established simultaneously, which could affect the scalability of the MQTT system.

Now that we understand how MQTT clients behind NAT establish connections with brokers, let’s take a closer look at the MQTT CONNECT command message and its contents.

How does the MQTT client initiate a connection through the CONNECT message?

Now let’s look at the MQTT CONNECT command message that the client sends to the broker to initiate a connection. If this message is incorrectly formatted or if there is too long a delay between opening the network socket and sending the CONNECT message, the broker will terminate the connection to prevent malicious clients that may slow down the broker’s performance. In addition to other details specified in the MQTT 3.1.1 specification, a friendly MQTT 3 client will also send the following.

Let’s look at some elements included in the MQTT CONNECT message, such as ClientId, Clean Session, Username/Password, Will Message, Keep Alive, etc.

ClientId is a unique identifier used to distinguish each MQTT client connected to the broker and allows the broker to track the current state of the client. To ensure uniqueness, the ClientId should be specific to each client and broker. MQTT 3.1.1 allows the use of an empty ClientId if the broker does not need to maintain the client’s state. However, this connection must set the clean session flag to true; otherwise, the broker will reject the connection.

The CleanSession flag indicates whether the client wishes to establish a persistent session with the broker. When CleanSession is set to false (CleanSession = false), it is considered a persistent session, and the broker will store all subscriptions and any missed messages with a Quality of Service (QoS) level of 1 or 2 for the client. Conversely, when CleanSession is set to true (CleanSession = true), the broker will not retain any information for the client and will discard any previous persistent session state.

MQTT provides the option to include a username and password for client authentication and authorization. However, it is important to note that sending this information in plaintext poses security risks. To mitigate this risk, we strongly recommend using encryption or hashing (e.g., via TLS) to protect credentials. We also recommend using a secure transport layer when transmitting sensitive data.

Additionally, some brokers (such as HiveMQ) offer SSL certificate authentication, completely eliminating the need for username and password credentials. Taking these precautions ensures that your MQTT communications remain secure and protected from potential security threats.The MQTT Last Will and Testament (LWT) feature includes a will message that notifies other clients when a client unexpectedly disconnects. This message can be specified by the client as an MQTT message and topic in the CONNECT message. When a client disconnects unexpectedly, the broker will send the LWT message on behalf of the client. For more information about the MQTT Last Will and Testament, please stay tuned for our future posts.The MQTT keep alive feature allows the client to specify a time interval in seconds and communicate it to the broker when establishing the connection. This interval determines the maximum period during which the broker and client can maintain communication without sending messages. To ensure the connection remains active, the client periodically sends PING Request messages, and the broker responds with PING responses. This method allows both parties to determine if the other is still available. For more information about the MQTT Keep Alive feature, please stay tuned for our future thematic posts.When connecting an MQTT client to an MQTT broker, maintaining the keep alive interval is essential. However, some MQTT libraries also have additional configuration options, such as how queued messages are stored in specific implementations.

MQTT Broker Response: CONNACK Message

When the broker receives a CONNECT message, it must respond with a CONNACK message.

CONNACK message contains two data items:

• The session present flag 会话标志

• A connect return code 连接返回码

The session present flag informs the client whether there is a previous session on the broker. If the client requests a clean session, this flag will always be false, indicating that there is no previous session.

However, if the client requests to resume a previous session, this flag will be true if the broker still stores session information. This flag helps the client determine whether it needs to re-subscribe to topics or if the broker still retains the previous session’s subscription information.

The return code is a status code used to inform the client of the success or failure of the connection attempt. This code can indicate various types of errors, such as invalid credentials or unsupported protocol versions.Here is an overview of the return codes:

For detailed information on each entry of these codes, please refer to the MQTT specification.

It is important to note the connection return code, as it helps diagnose connection issues. For example, if the return code indicates authentication failure, the client can attempt to reconnect using the correct credentials. Understanding the session present flag and connection return code is crucial for successfully establishing an MQTT connection.

Conclusion

In summary, understanding the roles of MQTT clients and brokers, as well as the connection establishment process, is essential for anyone looking to use the MQTT protocol. MQTT client libraries make it easy to add MQTT support to applications and devices without having to implement the protocol from scratch. MQTT brokers are responsible for receiving, filtering, and sending messages to subscribed clients, as well as handling client authentication and authorization.

With this knowledge, you can build scalable and efficient IoT systems using MQTT. If you want to learn more about the MQTT protocol, we strongly recommend reading other articles in the MQTT essentials series and exploring the available libraries and resources.

For more content, please stay tuned! If you have any questions about this issue, feel free to discuss in the comments!

Reference Links:

1. https://www.hivemq.com/mqtt-toolbox/

2. https://www.influxdata.com/mqtt/

3. https://www.spiceworks.com/tech/iot/articles/what-is-mqtt/

• 【Video Course】Codesys V3.5 Series Introduction Course(138 people have learned)
• 【Video Course】Codesys SoftMotion Basics Course(39 people have learned)
• 【Video Course】Codesys SoftMotion Electronic Gear Course(12 people have learned)
• 【Video Course】Codesys SoftMotion Electronic Cam Course(9 people have learned)
• 【Video Course】Codesys Library Custom Library Creation(22 people have learned)

• Codesys V3.5 Series Comprehensive Free Public Data Collection

• Top Ten Common Filtering Algorithms (ST Language)

• What does a PLC integrated with Chat GPT look like?

• Sharing the Top 10 PLC Programming Books of 2023

• Customize your own CODESYS motion controller

• MC_Power.status = FALSE, can the axis still move?

• ST Language Learning Resource Collection

——–END——–

If you like this article, please share and “like” it below and “keep watching”!