Create Your Own IM Social App with MQTT

简介: Message Queue Telemetry Transport (MQTT) is an instant communication protocol based on the publish-subscribe pattern.

CreateYourOwnIMSocialAppwithMQTT

Introduction

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:

1. Creating the Parent Topic in Advance

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:

  • Defines the first level of the topic as parent topic.
  • Creates parent topic in the MQ Console before using MQ.
  • No need to create child topics.
  • Child topics used directly in code.

2. Supporting Peer-to-Peer (P2P) Without Showing Subscribers

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:

  1. Do not include "/" and spaces in the name.
  2. Keep topics short and concise.
  3. Use UTF-8 encoding to avoid unreadable characters.
  4. Consider embedding the unique device number into the topic in specific scenarios to facilitate identification of message senders. For example, only client1 is allowed to publish messages to client1/status and not to client2/status. When you receive messages from client1/status, you can be sure that client1 sent the message.
  5. Use the wildcard character "#" with caution. For example, if you subscribe to news/sport/#, you will receive all messages from news/sport, such as news/sport/player1, news/sport/player2, and news/sport/player1/score. This can overload the receiving terminal (mobile terminal or embedded device).
  6. Scalable - The subscription relationship should be created first so the sender and receiver can understand the existence of topics in advance. An intelligent topic structure design allows for the addition of only child topics when a new business demand emerges, without changing the parent topics or overthrowing the original topic structure.
    For example, you can design the news about Li Na in the news/lina structure. However, there could be other people named Li Na in the cultural, sports, and entertainment circles. If users want to subscribe to news about Li Na specifically in the tennis circle, the topic structure has to be changed. The suggested designs below will produce better results:

news/sport/tennis/lina
news/sport/tennis/lina/ranking
news/sport/tennis/lina/score/australianopen

Implementation of Social IM with MQTT

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:

  • Group ID: The Group ID is applied and created in the MQ Console. It is used to specify the name of a group of nodes with the same logic and functions, representing a category of devices with the same tasks.
  • Device ID: The Device ID is the unique identifier of every device. The business entity specifies the Device ID, and you do not need to create it in the MQ Console.

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:

  • User A uses device GID_IMS@@@DeviceID_A
  • User B uses device GID_IMS@@@DeviceID_B
  • User C uses device GID_IMS@@@DeviceID_C

Scenario 1: User A requests to add User B as a friend for one-to-one chat

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.

01

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.

02

Scenario 2: User A follows User B's updates and receives updates when User B updates his profile

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.

03

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).

04

Scenario 3: User A invites User B and User C to join a group chat. User B and User C are not friends. Both are friends with 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.

05

Scenario 4: Send messages to a group of friends at holidays (not group chat)

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.

06

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.

Scenario 5: Commercial marketing - the system pushes messages to users in different categories/with different positioning

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).

For example:
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.

07

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).

Conclusion

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.

相关实践学习
消息队列RocketMQ版:基础消息收发功能体验
本实验场景介绍消息队列RocketMQ版的基础消息收发功能,涵盖实例创建、Topic、Group资源创建以及消息收发体验等基础功能模块。
消息队列 MNS 入门课程
1、消息队列MNS简介 本节课介绍消息队列的MNS的基础概念 2、消息队列MNS特性 本节课介绍消息队列的MNS的主要特性 3、MNS的最佳实践及场景应用 本节课介绍消息队列的MNS的最佳实践及场景应用案例 4、手把手系列:消息队列MNS实操讲 本节课介绍消息队列的MNS的实际操作演示 5、动手实验:基于MNS,0基础轻松构建 Web Client 本节课带您一起基于MNS,0基础轻松构建 Web Client
目录
相关文章
|
5月前
|
前端开发 JavaScript API
React团队回应用Vite替换Create React App的建议
React团队回应用Vite替换Create React App的建议
141 0
|
Java Android开发 数据安全/隐私保护
im即时通讯开发/聊天软件系统/社交APP源码搭建/私有化部署聊天原生开发源码快速搭建
由IM技术专家打造的基于 Java 实现的即时通讯(IM)项目 我们提供私有化即时通讯解决方案,独立部署在您自己的服务器上、代码可以开源、支持二次开发、苹果端上线指导,源码出售,提供远程技术指导,全程指导服务器部署打包. 特点:原生开发 超高并发 音视频通话
im即时通讯开发/聊天软件系统/社交APP源码搭建/私有化部署聊天原生开发源码快速搭建
|
2月前
|
网络协议 物联网 测试技术
App Inventor 2 MQTT拓展入门(保姆级教程)
本文演示的是App和一个测试客户端进行消息交互的案例,实际应用中,我们的测试客户端可以看着是任意的、支持MQTT协议的硬件,通过订阅及发布消息,联网硬件与我们的App进行双向数据通信,以实现万物互联的智能控制效果。
152 2
|
2月前
|
SQL 数据库 Windows
【应用服务 App Service】当使用EntityFrameWorkCore访问Sql Server数据库时,在Azure App Service会出现Cannot create a DbSet for ** because this type is not included in the model for the context的错误
【应用服务 App Service】当使用EntityFrameWorkCore访问Sql Server数据库时,在Azure App Service会出现Cannot create a DbSet for ** because this type is not included in the model for the context的错误
|
5月前
|
移动开发 网络协议 Linux
We discovered one or more bugs in your app when reviewed on iPhone and iPad running iOS 14.1
We discovered one or more bugs in your app when reviewed on iPhone and iPad running iOS 14.1
56 0
|
5月前
|
Java 数据库连接 Spring
【SpringBoot】Error starting ApplicationContext. To display the conditions report re--run your app
【SpringBoot】Error starting ApplicationContext. To display the conditions report re--run your app
212 0
|
存储 缓存 前端开发
Create React App 被 React 官方抛弃了吗?
在 Beta 版本的 React 新文档中,是有在显眼的位置提到推荐使用 Vite 启动的,而正式版文档则替换成了 React 社区的几个知名框架:
|
存储 API Go
苹果审核新要求Offering account deletion in your app
苹果审核新要求Offering account deletion in your app
198 0
|
前端开发
React学习笔记(六) Create React App
React学习笔记(六) Create React App
110 0
|
存储 安全 Android开发
私有化IM即时通讯APP聊天软件搭建
简介: 小苹果IM是由IM技术专家打造的专业的即时通讯软件。小苹果IM包括IM服务端和客户端,实现了高性能、轻量级、易安装等重要特性。客户通过私有化部署服务端,可以将即时通讯、实时网络能力快速集成到自身生产经营中,并确保业务数据的安全性和私密性。
私有化IM即时通讯APP聊天软件搭建