In most cases, live streaming for education involves multiple channels, and each channel has multiple members. This topic describes how to use ApsaraMQ for MQTT to mute a member and send interaction messages, client status notifications, and system notifications during live streaming. In the sample scenarios provided in this topic, one teacher and two students are in a single channel. The teacher and students use HTML web clients. The backend applications are developed in Java.
Background information
ApsaraMQ for MQTT must be used together with backend message storage queues. Currently, only queues in ApsaraMQ for RocketMQ can be used as backend message storage queues. For more information, see Message structure mappings between Message Queue for MQTT and Message Queue for Apache RocketMQ.
When you use a ApsaraMQ for MQTT client to send and receive messages, the Message Queue for MQTT broker authenticates the client based on the Username and Password parameters that you configured for the client. The definitions of the Username and Password parameters vary based on the authentication scenario. In the sample scenarios of this topic, token-based authentication is used. For more information, see Overview of token-based authentication.
This topic does not describe the operations on other products that are involved in live streaming for education. For information about operations on other products, see Best practices of live streaming for education.
For information about the terms that are used in this topic, see Terms.
Description of the sample scenarios
One teacher and two students are involved in each of the four online education scenarios provided in this topic. The teacher and students use different Message Queue for MQTT clients and have different group IDs and device IDs. To prevent consumption loops in ApsaraMQ for RocketMQ, the topic that you create for the clients in a channel to send messages must be different from the topic that you create for the clients in the channel to subscribe to messages. The following sections describe the scenarios.
Scenario 1: Send interaction messages
For example, one teacher and two students are in a live streaming channel. If you want all members in the channel to receive a text message from Student A, you can associate the channel with topics in Message Queue for MQTT. For example, the clients can use the roomSend/message topic to send messages and use the room/message/123456 topic to subscribe to messages, where:
roomSend is the parent topic that is used by all clients in the channel to send messages. You must create the topic in the ApsaraMQ for MQTT console.
room is a parent topic used by all clients in the channel to subscribe to messages. You must create the topic in the ApsaraMQ for MQTT console.
/message is a custom level-2 topic. You do not need to create the topic in the ApsaraMQ for MQTT console. In this example, /message indicates the text message.
/123456 is a custom level-3 topic. You do not need to create the topic in the ApsaraMQ for MQTT console. In this example, /123456 is the ID of the channel.
All members in the same channel subscribe to the room/message/123456 topic. The following figure shows the message flow.
The preceding process consists of the following steps:
Student A uses the client to send a message to Message Queue for MQTT. Sample message:
topic: "roomSend/message",body: "{ 'peer': 'xxx', 'roomId': '123456', 'msg': 'xxx' }"NoteMessages that are sent by using HTML web clients are in the JSON format.
ApsaraMQ for MQTT forwards the message to ApsaraMQ for RocketMQ based on the created data outflow rule.
The backend application that subscribes to the topic in ApsaraMQ for RocketMQ consumes the message to implement business processing, such as content moderation.
The backend application sends the processed message to the topic in ApsaraMQ for RocketMQ.
ApsaraMQ for RocketMQ forwards the message to ApsaraMQ for MQTT based on the created data inflow rule.
ApsaraMQ for MQTT pushes the message to all web clients, including the clients of the teacher, Student A, and Student B.
Scenario 2: Mute a member
This is a common scenario in which the point-to-point (P2P) messaging feature of ApsaraMQ for MQTT is used. In this scenario, a command message that indicates a student is muted by the teacher is sent to the client of the muted student. At the same time, the broker adds a muted member list for service verification and message filtering. The teacher client needs to send the message to the roomSend/command topic, where:
roomSend is a parent topic that is used by all clients in the channel to send messages. You must create the topic in the ApsaraMQ for MQTT console.
command is a custom level-2 topic. You do not need to create the topic in the ApsaraMQ for MQTT console. The command topic is different from the message level-2 topic and is used to send command messages.
You do not need to subscribe to P2P messages. In this scenario, the sample value is room/p2p/GID_student@@@002.
The following figure shows the message flow.
The preceding process consists of the following steps:
The teacher uses the client to send a command message to ApsaraMQ for MQTT to mute a student.
ApsaraMQ for MQTT forwards the message to ApsaraMQ for RocketMQ based on the created data outflow rule.
The backend application that subscribes to the topic in ApsaraMQ for RocketMQ receives the command message, verifies the message, and then saves the muted member list. This way, messages from the muted student can be filtered. The backend application also sends a P2P message room/p2p/GID_student@@@002 to the client of Student B to display the muting effect on the client.
Scenario 3: Send client status notifications
The asynchronous notification feature of ApsaraMQ for MQTT ensures that all members in the channel can receive notifications when other members come online and go offline. In this scenario, all clients must subscribe to the room/status topic, where:
room is the parent topic. You must create the topic in the ApsaraMQ for MQTT console.
status is a custom level-2 topic. You do not need to create the topic in the ApsaraMQ for MQTT console. In this example, status indicates messages related to client status.
After all Message Queue for MQTT clients subscribe to this topic, Message Queue for MQTT triggers an event message and sends the message to ApsaraMQ for RocketMQ when a client comes online or goes offline. The following figure shows the message flow.
The preceding process consists of the following steps:
ApsaraMQ for MQTT sends the notification about Student A coming online to ApsaraMQ for RocketMQ based on the created rule for sending notifications about online and offline events.
The backend application that subscribes to the topic in ApsaraMQ for RocketMQ consumes the message and implements business processing, such as attendance recording.
The backend application sends the processed message to the topic in ApsaraMQ for RocketMQ.
ApsaraMQ for RocketMQ forwards the message to ApsaraMQ for MQTT based on the created data inflow rule.
ApsaraMQ for MQTT broadcasts the message to all clients, including the clients of the teacher, Student A, and Student B.
Scenario 4: Send system notifications
In this scenario, the messaging feature of ApsaraMQ for MQTT is used. Notifications about system updates are sent to all members in the channel. In this scenario, all clients must subscribe to the room/system topic, where:
room is the parent topic. You must create the topic in the ApsaraMQ for MQTT console.
system is a custom level-2 topic. You do not need to create the topic in the ApsaraMQ for MQTT console. In this example, system indicates messages that are sent by the system.
The following figure shows the message flow.
The preceding process consists of the following steps:
The backend application sends the notification about a system update to the topic in ApsaraMQ for RocketMQ.
ApsaraMQ for RocketMQ forwards the message to ApsaraMQ for MQTT based on the created data inflow rule.
ApsaraMQ for MQTT pushes the message to all the clients, including the clients of the teacher, Student A, and Student B.
Process
The following figure shows the process of the sample scenarios of live streaming for education. The sample code that is used for the SDKs varies because different features of ApsaraMQ for MQTT are used in each scenario. For more information, see the description of each scenario.
Procedure
Create the following resources in the ApsaraMQ for MQTT console.
Resource
Example
References
Instance
N/A
Parent topic (level-1 topic)
room: a parent topic to which all clients in the channel subscribe.
roomSend: a parent topic that all clients in the channel use to send messages.
Subtopic
The following items describe the subtopics that are used in the sample scenarios:
Send interaction messages: /message/123456
Mute a student: /command and /p2p/GID_student@@@002. This is a typical point-to-point (P2P) message scenario.
Send client status notifications: /status
Send system notifications: /system
NoteYou do not need to create subtopics. For more information, see Terms.
N/A
Group ID
Teacher: GID_teacher
Students: GID_student
The following table shows the mappings between the clients of the teacher and students, and the groups to which the clients belong.
Role
Group ID
Device ID
Client ID
Teacher
GID_teacher
001
GID_teacher@@@001
Student A
GID_student
001
GID_student@@@001
Student B
GID_student
002
GID_student@@@002
NoteYou do not need to create a device ID. For more information, see Terms.
Run the sample code that ApsaraMQ for MQTT provides for your client and backend application to receive and send messages in different scenarios.
The following items describe the download URLs for sample code:
NoteConfigure the parameters in code based on the comments.