Promo Center

50% off for new user

Direct Mail-46% off

Learn More

Live streaming interaction solution

Updated at: 2023-08-25 06:13

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.

Note

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
Scenario 2: Mute a member
Scenario 3: Send client status notifications
Scenario 4: Send system notifications

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.

Scenario 1

The preceding process consists of the following steps:

  1. 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' }"
    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 outflow 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 inflow rule.

  6. ApsaraMQ for MQTT pushes the message to all web clients, including the clients of the teacher, Student A, and Student B.

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.

Scenario 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 outflow 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.

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.

Scenario 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 notifications about online and offline events.

  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 inflow rule.

  5. ApsaraMQ for MQTT broadcasts the message to all clients, including the clients of the teacher, Student A, and Student B.

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.

Scenario 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 inflow 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 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.

live_house_process

Procedure

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

    Resource

    Example

    References

    Resource

    Example

    References

    Instance

    N/A

    Quick Start

    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.

    Quick Start

    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

    Note

    You do not need to create subtopics. For more information, see Terms.

    N/A

    Group ID

    • Teacher: GID_teacher

    • Students: GID_student

    Quick Start

    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

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

  2. 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:

    Note

    Configure the parameters in code based on the comments.

Terms

  • MQTT

    • 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 used for terminal applications.

  • Message Queue for MQTT broker

    • A broker provided by ApsaraMQ for MQTT for MQTT-based interactions. A Message Queue for MQTT broker is responsible for messaging between a Message Queue for MQTT client and ApsaraMQ for RocketMQ.
  • Message Queue for MQTT client

    • A mobile node that interacts with a ApsaraMQ for MQTT broker.
  • parent topic

    • MQTT is a messaging protocol based on the publish-subscribe model. Therefore, each message belongs to a topic. The MQTT protocol supports multiple levels of topics. A level-1 topic is a parent topic. 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 Message Queue for MQTT. You can specify subtopics in your application code without the need to create subtopics in the Message Queue for MQTT console. You can specify the subtopics in the following format: <Name of the parent topic>/<Name of the level-2 topic>/<Name of the level-3 topic>. The parent topic and the subtopics are separated with forward slashes (/). Example: SendMessage/demo/producer. Take note that the total length of a parent topic and its subtopics cannot exceed 64 characters in ApsaraMQ for MQTT. Otherwise, client exceptions occur.

  • client ID

    • An identifier that globally and uniquely identifies a client in ApsaraMQ for MQTT. If a client uses 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 two parts in the format of <GroupID>@@@<DeviceID>. A client ID cannot exceed 64 characters in length and cannot contain non-printable characters. For more information, see Limits.

  • group ID

    • An identifier that specifies a group of nodes that use identical logic and features. A group ID represents a set of devices that support the same features. If you want to use a group, you must create it in the ApsaraMQ for MQTT console.

  • device ID

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

    • A special type of message provided by ApsaraMQ for MQTT based on the standard MQTT protocol. This type of message can be sent to a Message Queue for MQTT client without subscriptions. For more information, see P2P messaging for Message Queue for MQTT.
  • RTC server

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

    RTC is 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.

  • On this page (1, T)
  • Background information
  • Description of the sample scenarios
  • Process
  • Procedure
  • Terms
Feedback
phone Contact Us

Chat now with Alibaba Cloud Customer Service to assist you in finding the right products and services to meet your needs.

alicare alicarealicarealicare