All Products
Search

This Product

    ApsaraMQ for MQTT:Live streaming interaction solution

    Document Center

    ApsaraMQ for MQTT:Live streaming interaction solution

    Last Updated:Jan 30, 2024

    In most cases, live streaming for online 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

    To implement data exchange between ApsaraMQ for MQTT and ApsaraMQ for RocketMQ in live streaming interaction, you must create the corresponding data exchange rules, including the data inbound rule, the data outbound rule, and the rule for sending client status notifications. For more information, see Import data from other cloud services to ApsaraMQ for MQTT, Export data from ApsaraMQ for MQTT to other Alibaba Cloud services, and Export status events of ApsaraMQ for MQTT clients.

    When you use an ApsaraMQ for MQTT client to send and receive messages, the ApsaraMQ 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.

    For information about the terms that are used in this topic, see the "Terms" section of this topic.

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

    • room is a parent topic that is 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.

    场景1

    The preceding process consists of the following steps:

    1. Student A uses the client to send a message to ApsaraMQ for MQTT. Sample message:

      topic: "roomSend/message", body: "{ 'peer': 'xxx', 'roomId': '123456', 'msg': 'xxx' }"
      Note

      Messages that are sent by using HTML web clients are in the JSON format.

    2. ApsaraMQ for MQTT forwards the message to ApsaraMQ for RocketMQ based on the created data outbound rule.

    3. The backend application that subscribes to the topic in ApsaraMQ for RocketMQ consumes the message to implement business processing, such as content moderation.

    4. The backend application sends the processed message to the topic in ApsaraMQ for RocketMQ.

    5. ApsaraMQ for RocketMQ forwards the message to ApsaraMQ for MQTT based on the created data inbound rule.

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

    Note

    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.

    场景2

    The preceding process consists of the following steps:

    1. The teacher uses the client to send a command message to ApsaraMQ for MQTT to mute a student.

    2. ApsaraMQ for MQTT forwards the message to ApsaraMQ for RocketMQ based on the created data outbound rule.

    3. 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 a 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 ApsaraMQ for MQTT clients subscribe to this topic, ApsaraMQ 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.

    场景3

    The preceding process consists of the following steps:

    1. ApsaraMQ for MQTT sends the notification about Student A coming online to ApsaraMQ for RocketMQ based on the created rule for sending client status notifications.

    2. The backend application that subscribes to the topic in ApsaraMQ for RocketMQ consumes the message and implements business processing, such as attendance recording.

    3. The backend application sends the processed message to the topic in ApsaraMQ for RocketMQ.

    4. ApsaraMQ for RocketMQ forwards the message to ApsaraMQ for MQTT based on the created data inbound rule.

    5. 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 a 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.

    场景4

    The preceding process consists of the following steps:

    1. The backend application sends the notification about a system update to the topic in ApsaraMQ for RocketMQ.

    2. ApsaraMQ for RocketMQ forwards the message to ApsaraMQ for MQTT based on the created data inbound rule.

    3. 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 four sample scenarios of live streaming for online education. The 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.

    live_process_v3.x.x

    Procedure

    1. Create the following resources in the ApsaraMQ for MQTT console.

      Resource

      Example

      References

      Instance

      post-cn-0pp12gl****

      Step 1: Create an ApsaraMQ for MQTT instance and obtain the endpoint of the instance

      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.

      Manage topics

      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 scenario in which the P2P messaging feature is used.

      • Send client status notifications: /status

      • Send system notifications: /system

      Note

      You do not need to create subtopics. For more information, see the "Terms" section of this topic.

      N/A

      Group ID

      • Teacher: GID_teacher

      • Students: GID_student

      Manage groups

      Rule

      • Data inbound rule

      • Data outbound rule

      • Rule for sending client status notifications

      The following table shows the mappings between the clients of the teacher and students and the groups to which they 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

      Note

      You do not need to create a device ID. For more information, see the "Terms" section of this topic.

    2. Execute the sample code that ApsaraMQ for MQTT provides for the client and backend application to receive and send messages in different scenarios.

      The following items describe the download URLs for sample code:

      Note

      Configure parameters in the code based on the comments.

    Terms

    • MQTT

      • Short for Message Queuing Telemetry Transport. It is a publish-subscribe messaging protocol that is used to establish persistent connections for bi-directional communication. MQTT supports simple and flexible subscriptions and is suitable for sending interaction messages during live streaming. ApsaraMQ for MQTT is based on the standard MQTT protocol and is widely used for terminal applications.

    • ApsaraMQ for MQTT broker

      • A server node provided by ApsaraMQ for MQTT for MQTT-based interactions. ApsaraMQ for MQTT brokers are used to implement messaging with ApsaraMQ for MQTT clients and ApsaraMQ for RocketMQ.

    • ApsaraMQ for MQTT client

      • A mobile node that is used to interact with an ApsaraMQ for MQTT broker.

    • parent topic

      • MQTT is a messaging protocol that is based on the publish-subscribe (pub/sub) model. In MQTT, each message belongs to a topic. The MQTT protocol supports multiple topic levels. Level-1 topics are parent topics. Before you use ApsaraMQ for MQTT, you must create a parent topic in the ApsaraMQ for MQTT console or the ApsaraMQ for RocketMQ console.

    • subtopic

      • A level-2 topic or level-3 topic is a subtopic of a parent topic in ApsaraMQ for MQTT. You can specify subtopics in your application code without the need to create subtopics in the ApsaraMQ for MQTT console. The name of a subtopic is in the <Name of parent topic>/<Name of level-2 topic>/<Name of level-3 topic> format. The parent topic and its subtopics are separated by forward slashes (/). Example: SendMessage/demo/producer. The name of a subtopic cannot exceed 64 characters in length in ApsaraMQ for MQTT. Otherwise, exceptions can occur on the client.

    • client ID

      • An identifier that globally and uniquely identifies a client in ApsaraMQ for MQTT. If you use a client ID that has been used by another client to access ApsaraMQ for MQTT, the access request is denied.

        A client ID consists of a group ID and a device ID. The format of a client ID is <GroupID>@@@<DeviceID>. A client ID cannot exceed 64 characters in length and cannot contain non-printable characters. For more information, see Limits.

    • group ID

    • device ID

      • An identifier that you specify to uniquely identify each device. A device ID must be globally unique. For example, you can use the serial number of a sensor as the device ID.

    • P2P messaging

      • A special messaging model provided by ApsaraMQ for MQTT based on the standard MQTT protocol. In this messaging model, messages can be sent to an ApsaraMQ for MQTT client without subscription. For more information, see P2P Messaging model (MQTT).

    • RTC server

      • A server that hosts audio-and-video media channel services provided by Alibaba Cloud Real-Time Communication (RTC).

    • RTC

      A global real-time audio and video development platform provided by Alibaba Cloud. The platform depends on core audio and video encoding and decoding, channel transmission, and network scheduling technologies to provide high-availability, high-quality, and ultra-low-latency audio and video communication services. This way, users can quickly build multi-end real-time applications. RTC is suitable for scenarios such as online education, video conferencing, interactive entertainment, and audio and video social networking.