The core of the MQTT protocol is the publish-subscribe model. In this article, we will introduce this mode in detail.
The publish-subscribe model is different from the traditional client-server model. It separates the client (publisher) that sends the message from the client (subscriber) that receives the message. The publisher and the subscriber do not need to establish direct contact. We can either let multiple publishers publish messages to one subscriber, or let multiple subscribers receive messages from one publisher at the same time. The essence of it is that an intermediate role called a broker is responsible for all message routing and distribution. The traditional client-server model can achieve similar results, but it cannot be as simple and elegant as the publish-subscribe model.
The advantage of the publish-subscribe model is the decoupling of publishers and subscribers. This decoupling is manifested in the following two aspects:
As the key role of the publish-subscribe model, the broker needs to accurately and efficiently forward the desired messages to the subscribers. Generally speaking, there are two methods:
The loosely-coupled nature of the publish-subscribe model also has some side effects. Since the publisher is not aware of the subscriber's status, the publisher cannot know whether the subscriber has received the message or whether the message has been processed correctly. In such cases, securing delivery often requires a more interactive flow of messages. For example, a subscriber sends a response to a topic after receiving a message, and the publisher is now a subscriber waiting for a response.
The MQTT protocol distributes messages based on topics rather than message content. Each message contains a topic, and the broker does not need to parse user data. This provides the possibility to implement a general, business-independent MQTT broker. Users can also encrypt their data at will, which is very useful for WAN communication.
MQTT topics can have multiple levels, and allow fuzzy matching of one or more levels, enabling clients to subscribe to multiple topics at once. We will introduce the detailed features of the MQTT topic in the following articles.
Compared with message queuing, MQTT does not require the topic to be created explicitly before publishing or subscribing. The only possible adverse effect is that the client may use the wrong topic without knowing it, but the benefit of flexible deployment is higher than that.
Since we have mentioned message queues, it is time to explain the difference between MQTT and message queues. MQTT is not a message queue, although many behaviors and characteristics of the two are very close, such as using a publish-subscribe model. The scenarios they face are significantly different. Message queues are mainly used for message storage and forwarding between server-side applications. In this kind of scenario, the data volume is often large but the access volume is small. MQTT is targeted at the IoT field and the mobile Internet field. The focus of such scenarios is massive device access, management and messaging. In practical scenarios, the two are often used in combination. For example,MQTT Broker first receives data uploaded by IoT devices, and then forwards these data to specific applications for processing through message queues.
Hopefully, with this short article, you will have an intuitive understanding of the publish-subscribe model. Other features of MQTT will be covered in subsequent articles.