
When introducing communication protocols, understanding their communication architecture is crucial for a clear understanding of their working principles and mechanisms.
Just as OPC UA follows the Server and Client framework of OPC, what framework does MQTT follow?

MQTT Publish / Subscribe Architecture
The MQTT protocol operates based on the publish/subscribe model. In traditional network communication, clients and servers communicate directly with each other. The client requests resources or data from the server, which processes the request and sends back a response. However, MQTT uses the publish/subscribe model to decouple the message sender (publisher) from the message receiver (subscriber). Instead, a third component, acting as a message broker, handles the communication between publishers and subscribers. The broker’s job is to filter all incoming messages from publishers and distribute them correctly to subscribers.
For example, consider the two devices Device1 and Device2:
- Device 1 publishes to a topic.
- Device 2 subscribes to the same topic published by Device 1.
- Thus, Device 2 receives the message.

MQTT Client and Broker
MQTT Clients and Brokers
As mentioned in the architecture above, the client publishes messages to different topics, which are received by the broker and filtered based on the topics. The broker then sends these messages to the respective clients that have subscribed to those different topics.

The core of any publish/subscribe protocol is the MQTT broker. Depending on its implementation, a broker can handle thousands of simultaneously connected MQTT clients. All communication must be received by the broker, which then classifies it, determines who has subscribed to each topic, and sends the messages to the subscribed clients. The broker also maintains all persistent sessions, including missed messages and subscriptions.
The broker’s job is to filter all incoming messages from publishers and distribute them correctly to subscribers. The broker decouples publishers and subscribers, as shown below:
-
Spatial Decoupling: Publishers and subscribers do not know each other’s network locations and do not exchange information such as IP addresses or port numbers.
-
Temporal Decoupling: Publishers and subscribers do not need to be running or have a network connection at the same time.
-
Synchronous Decoupling: Publishers and subscribers can send or receive messages without interfering with each other. For example, subscribers do not have to wait for publishers to send messages.

Working of MQTT
How MQTT Works
The MQTT publish/subscribe (pub/sub) communication model is designed to maximize available bandwidth and serves as an alternative to the traditional client-server architecture that communicates directly with endpoints. In the pub/sub model, there is no direct connection between the client that publishes messages (the publisher) and the client that receives messages (the subscriber). A third party—the broker—manages the relationship between publishers and subscribers, as they do not communicate directly with each other.
Publishers and subscribers refer to the two functionalities of an MQTT client, where a client can either publish messages or subscribe to receive messages. The same MQTT client can implement both functionalities simultaneously. When a client or device wants to submit data to the server or broker, publishing occurs.

“Subscribing” refers to the reverse operation of this process. In the pub/sub model, multiple clients can connect to the broker and subscribe to topics of interest.
When the broker and the subscribing client lose connection, the broker stores messages in a buffer and sends them to the subscriber once the broker is back online. If the publishing client suddenly disconnects from the broker, the broker has the authority to interrupt communication with the subscriber and send cached messages containing instructions from the publisher.
“The publisher sends messages, and the subscriber receives messages of interest; the broker delivers the publisher’s messages to the subscriber.” This is how IBM describes the publish/subscribe model. MQTT clients, such as publishers and subscribers, can only communicate with the MQTT broker. Any device or program running an MQTT library can become an MQTT client, from microcontrollers like Arduino to application servers hosted in the cloud.
Reference Links:
-
https://www.hivemq.com/blog/mqtt-essentials-part2-publish-subscribe/
-
https://aws.amazon.com/what-is/mqtt/
-
https://www.geeksforgeeks.org/introduction-of-message-queue-telemetry-transport-protocol-mqtt/

- 【Video Course】Introduction to Codesys V3.5 Series(138 people have learned)【Video Course】Codesys SoftMotion Basics Course(39 people have learned)
- 【Video Course】Codesys SoftMotion Electronic Gears Course(12 people have learned)
- 【Video Course】Codesys SoftMotion Electronic Cam Course(9 people have learned)
- 【Video Course】Creating Custom Libraries in Codesys(22 people have learned)
- Comprehensive Free Resources for Codesys V3.5 Series
-
Top 10 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
-
Can MC_Power.status = FALSE still allow the axis to move?
-
Summary of ST Language Learning Materials

——–END——–
If you like this article, please share and “like” it below and “view” it.