Message Queue Telemetry Transport (MQTT) is an instant communication protocol based on the publish-subscribe pattern. It is lightweight, open source, easy-to-use, and supports Quality of Service (QOS). These features, along with its low energy consumption, make MQTT suitable for applications such as the Internet of Things (IoT) and mobile Internet.
IBM Message Queue (MQ) provides support to MQTT protocol and is fully compatible with the MQTT standard protocol. When comparing MQTT with standard protocol during usage, the following two points highlighted:
Multiple levels of dynamic topics exist in the typical MQTT protocol, which eliminates the need to define and create them in advance. MQ topics are set up in advance in the MQ Console because MQTT is queue-oriented (for message persistence). MQ supports not only the MQTT protocol but also Transmission Control Protocol (TCP) and Hypertext Transfer Protocol (HTTP). To ensure intercommunication between messages of different access methods, MQTT provides the following adaptations:
P2P serves as a supplement to the standard MQTT protocol, which does not support P2P. All clients connected through the TCP/HTTP protocols can receive or send P2P messages.
The dynamic MQTT topics allow ample space for designers, but be sure to give careful attention to the following points:
Listed below are few scenarios about the implementation of social IM with MQTT:
Preparations: Create parent topics and Group ID in the MQ Console
A Client ID is required for every device to connect to the MQTT service. The Client ID is the client's unique identifier and should be globally unique.
The Client ID is composed of two parts:
We will create the parent topic IMS in the MQ Console and the GroupID of GID_IMS. We will assume the following for Device IDs:
Solution 1: Use P2P messaging
The advantage to P2P messaging is that both sides do not need to subscribe in advance. The disadvantage is that if DeviceID_B receives a friend request from multiple users at the same time, it is difficult to identify the sender of each request.
The identification is unavailable from the message topic. We can parse the message body to identify the sender.
Note: In P2P messaging, the secondary topic must contain the P2P text, and the tertiary topic is the target device's Client ID.
Solution 2: Design an inbox for every user and every user should subscribe to his/her inbox via the client login.
The advantage of this solution is that every user can parse the topic to know the sender of each incoming friend request and find out who has accepted the friend request.
When User B receives the message IMS/UserB/Inbox/Add/GFReq/UserA, User B knows User A sent the friend request.
When User A receives the message IMS/UserA/Inbox/Add/GFResp/UserB, User A knows it is User B's feedback.
To follow User B's updates, User A subscribes to IMS/UserB. When User B shares content, User B publishes it to IMS/UserB. Subscribers (i.e., friends) of IMS/UserB can view the post (MQTT is responsible for sending the message to all subscribers).
If User A does not want to see User B's profile updates, User A can cancel the subscription to IMS/UserB.
What if User B does not want User A to see User B's shared messages?
An inbox is also an option in this scenario. User A subscribes to IMS/UserA/Inbox/Update/# at login. User B sends a message to IMS/UserA/Inbox/Update/UserB/Unsub. After User A receives this message, User A cancels the subscription to IMS/UserB. User A will no longer see User B's Moments updates.
After User A receives User B's subscription cancellation request, it is the application designer's responsibility to determine whether to display a prompt box notifying User A (User B blacklists User A) or have it done silently (User B silently blacklists User A).
First, the group chat initiator, User A, subscribes to IMS/Group123/#. P2P messaging is used to invite User B and User C to join the group chat.
User B and User C subscribe to IMS/Group123/# to agree to join the conversation. User B can publish to IMS/Group123/UserB with User B's identity information in the group chat if User B wants to send a message to the group. This allows all members subscribed to IMS/Group123/# to see User B's message.
You can send P2P messages to friends one by one or send messages to your friend's inboxes. The disadvantage is you need to publish the message multiple times, depending on how many friends you want to receive the message.
Does a solution exist to reduce the effort involved in publishing multiple times?
MQTT intends to create a virtual group to simplify this process. Friends do not need to subscribe to this group explicitly. Instead, the subscription relationship is set up by the system dynamically based on the business configuration. Friends can receive messages sent to this group without noticing the existence of this group because the client did not initiate the action to subscribe to this virtual group (in a similar principle of P2P subscription).
MQTT does not support this feature currently.
If you want to send a New Year greeting to users in various regions with the message content varying according to the region, you can use P2P or inbox, as in scenario 4. However, this is not an ideal solution for the entire system since there are many users.
Since MQTT does not support virtual groups currently, how can we implement this function?
During the business design, a topic for system broadcasting is reserved, such as IMS/System. Every user, apart from subscribing to his/her inbox and friends, also subscribes to the system preserved topic based on the user's region (see Figure 7).
Beijing users are subscribed to IMS/System/Beijing
Hangzhou users are subscribed to IMS/System/Hangzhou
When the system sends a message to IMS/System/Beijing, all Beijing users will receive the message. Similarly, when the system sends a message to IMS/System/Hangzhou, all Hangzhou users will receive the message.
When a user logs into the client, the business application will identify the user's region first and make the user subscribe to the preserved topic of the area. However, this solution is not flexible enough because when the business expands in the future, the program will require updates (subscribe to new topics to meet the new market demand).
MQTT is efficient in scenarios where a small code footprint is needed. It also helps you create an instant messaging app easily and quickly. MQTT is a good solution for wireless networks with flexible latency caused by bandwidth constraints.
Alibaba Clouder - August 5, 2020
Alibaba Clouder - June 30, 2020
Aliware - November 10, 2020
Alibaba Cloud Storage - May 8, 2019
Alibaba Clouder - November 10, 2017
Alibaba Clouder - December 16, 2020
A message service designed for IoT and mobile Internet (MI).Learn More
A messaging service that covers the globe, Alibaba SMS provides convenient, efficient, and intelligent communication capabilities that help businesses quickly contact their customers.Learn More
A distributed, fully managed, and professional messaging service that features high throughput, low latency, and high scalability.Learn More
AlibabaMQ for Apache RocketMQ is a distributed message queue service that supports reliable message-based asynchronous communication among microservices, distributed systems, and serverless applications.Learn More
More Posts by Alibaba Clouder