Milestone 75 signaling docs revamp (#1174)

* reorganized the left navigation menu * quickstart doc structure * sdk integration * android updates * updates * android updates * 218 sdk quickstart milestone 75 (#1094) * obj-c updates * cpp setup * updates * linux updates * updates * cpp updates * unity setup * Unity updates * Web updates * Web quickstart updates * update * add event listener docs (#1086) * add event listener docs * review updates * review updates * review --------- Co-authored-by: saudsami <[email protected]> Co-authored-by: Saud <[email protected]> Co-authored-by: atovpeko <[email protected]> * Endoc 226 signaling stream channels (#1090) * stream channel docs * updates * update * review updates * review updates * review updates * review updates * review updates * language review --------- Co-authored-by: saudsami <[email protected]> Co-authored-by: Saud <[email protected]> Co-authored-by: atovpeko <[email protected]> * Connection basics (#1093) * updates * folders renamed * updates * review updates * other platform updates * image update * language review * review update --------- Co-authored-by: saudsami <[email protected]> Co-authored-by: Saud <[email protected]> Co-authored-by: atovpeko <[email protected]> * Endoc 225 signaling message channels (#1091) * Message channel docs * updates * changed message-channel shared folder * merge clean-up * more-cleanup * review updates * test * test build * build it * revert * testing workflows * test workflow2 * test workflow3 * workflow test4 * test workflow event * Update * language review --------- Co-authored-by: Saud <[email protected]> Co-authored-by: saudsami <[email protected]> Co-authored-by: atovpeko <[email protected]> * 234 Signaling Channel Naming Recommendations (#1107) * 234 Signaling Channel Naming Recommendations * review update * review updates * language review --------- Co-authored-by: Saud <[email protected]> Co-authored-by: saudsami <[email protected]> Co-authored-by: atovpeko <[email protected]> * ENDOC-235 Signaling - Message payload structuring (#1111) * ENDOC-235 Signaling - Message payload structuring * review updates * review --------- Co-authored-by: saudsami <[email protected]> Co-authored-by: atovpeko <[email protected]> * Endoc 240 signaling connection state migration and recovery (#1104) * updates * updates * updates * review-updates * updates * review updates * review updates * review updates * pulled from the milestone * review --------- Co-authored-by: saudsami <[email protected]> Co-authored-by: Saud <[email protected]> Co-authored-by: atovpeko <[email protected]> * connection-state-transitions platform updates * 222 Signaling Channel Basics (#1097) * ENDOC-222 Signaling - Channel basics * structure update * Review updates * review updates * language review --------- Co-authored-by: Saud <[email protected]> Co-authored-by: saudsami <[email protected]> Co-authored-by: atovpeko <[email protected]> * 227 Signaling Topics (#1092) * stream channel docs * updates * ENDOC-227 Signaling Topics * update * review updates * review updates * review updates * review updates * review updates * review updates * android updates * review updates * language review * update --------- Co-authored-by: hussain-khalid <[email protected]> Co-authored-by: saudsami <[email protected]> Co-authored-by: Saud <[email protected]> Co-authored-by: atovpeko <[email protected]> * Endoc 220 signaling secure authentication with tokens (#1096) * updates * updates * update * review updates * Token generator docs (#1098) * update * updates * review updates * review updates * language review --------- Co-authored-by: saudsami <[email protected]> Co-authored-by: Saud <[email protected]> Co-authored-by: atovpeko <[email protected]> * User and channel metadata docs (#1114) * User and channel metadata docs * updates * review updates * channel metadata review updates * review updates * channel metadata updates * user metadata review updates1 * updates * updates * Update android.mdx * updates * updates * review updates * language review * language alignment for quickstart --------- Co-authored-by: Saud <[email protected]> Co-authored-by: saudsami <[email protected]> Co-authored-by: atovpeko <[email protected]> * Endoc233-Signaling data encryption local milestone75 revamp (#1117) * ENDOC-233-data-encryption * review updates * review updates * language review --------- Co-authored-by: saudsami <[email protected]> Co-authored-by: Saud <[email protected]> Co-authored-by: atovpeko <[email protected]> * Endoc219-Signaling: Agora account management doc (#1121) * Endoc219-Signaling: Agora account management doc * update * update for Account and Billing part doc * Updates * updates * review updates * image updates * Update * language review --------- Co-authored-by: saudsami <[email protected]> Co-authored-by: Saud <[email protected]> Co-authored-by: atovpeko <[email protected]> * Client configuration docs (#1120) * cloud proxy docs * updates * review updates * review updates * updates * updates * updates * updates * review updates * review updates * language review * review updates --------- Co-authored-by: Saud <[email protected]> Co-authored-by: saudsami <[email protected]> Co-authored-by: atovpeko <[email protected]> * presence docs (#1119) * presence docs * updates * Updates * android updates * Updates * more updates * language review * review updates --------- Co-authored-by: saudsami <[email protected]> Co-authored-by: Saud <[email protected]> Co-authored-by: atovpeko <[email protected]> * Updates (#1127) * Update * Update * Updates * removed old docs * Updates * Endoc 294 pricing doc update (#1131) * updates * updates * update * review --------- Co-authored-by: atovpeko <[email protected]> * release notes 2.1.12 * updates * 2.2.0 release note android * api Updates * update * release notes * updates * Signaling updates + User channel doc (#1569) * updates * updates * review updates --------- Co-authored-by: saudsami <[email protected]> * Updates * cpp docs review updates * Added a restful authentication folder * Update * android drafted * ios and drafted * release notes * release notes * release notes * Signaling api ref update milestone 75 (#1164) * shared variable update * updates * updates * add error codes * fix * endoc-329 pricing update * Android API ref updates * ios updates * web updates * unity updates * linux-cpp updates --------- Co-authored-by: atovpeko <[email protected]> Co-authored-by: atovpeko <[email protected]> * release notes finalized * 2.2.1 docs updates milestone 75 (#1166) * cpp-connection-basics * cpp-connection-state-transitions * cpp-token-authentication * updates from cn rtm2-cpp2.2.1 --------- Co-authored-by: Hussain Khalid <[email protected]> Co-authored-by: atovpeko <[email protected]> Co-authored-by: Dasun Nirmitha <[email protected]> Co-authored-by: hussain-khalid <[email protected]> Co-authored-by: Pankajg123 <[email protected]> Co-authored-by: atovpeko <[email protected]>
AgoraIO · Aug 14, 2024 · f67fdab · f67fdab
1 parent b10c457
commit f67fdab
Show file tree

Hide file tree

Showing 525 changed files with 19,397 additions and 8,481 deletions.
diff --git a/assets/code/signaling/channel-basics/channel-types.mdx b/assets/code/signaling/channel-basics/channel-types.mdx
@@ -0,0 +1,64 @@
+<PlatformWrapper platform='android'>
+<Vg k="AGORA_BACKEND" /> channels can be categorized into three types according to their usage and message delivery methods, namely **Message Channel**, **User Channel**, and **Stream Channel** which are distinguished by the `channelType` parameter in the API. The main differences between the three channel types are as follows:
+
+    - **Message Channel**: This channel type uses a common communication method that follows a **publish-subscribe** model to deliver messages, similar to the **MQTT protocol**. When using this model, there is no need to create a channel in advance, just publish messages to a specific channel or subscribe to a specific channel to receive messages. Due to its flexibility, users can easily implement different topologies such as one-to-one channels, group channels, broadcast channels, unicast channels, and so on. Because this channel type usually has a large number of subscribers, there is no guarantee that all subscribers will send delivery receipts when they receive a message.
+    - **User Channel**: This channel type is used to send peer-to-peer messages to a specified `userId`. When you use it, just set the `channelType` parameter in the `publish` method to `USER` and the `channelName` parameter to the `userId` of the other party. You don't need to subscribe to receive messages, you just need to implement the `onMessageEvent` event listener. Because it is one-to-one message sending and receiving, this channel type supports the **delivery receipt** function. That is, after the sender sends a message, if the receiver is online and receives the message successfully, it will return `success`; if the receiver is not online or the reception fails, it will return `failure` or `timeout`. This channel type can only implement a one-to-one topology. Although you can judge whether the other party is online or not by the return value, we recommend using the `Presence` function for this.
+    - **Stream Channel**: This is a special type of channel that follows the room concept similar to the observer pattern. In this type of channel, users cannot send messages directly. User needs to call the `joinTopic` method first to register as the publisher of the topic before they can send messages. If the user wants to receive messages, they need to subscribe to the specified message publisher (identified by `userId`) in the specified topic. In addition, client-side messages support delivery at higher QPS. This channel type is often recommended for meta-universe, parallel driving, and cloud gaming scenarios.
+
+In addition, `Presence`, `Storage`, and `Lock` functions can be enabled in both **Message Channel** and **Stream Channel** as needed. However, **User Channels** cannot utilize these features and can be treated as a simple message pass-through channel.
+</PlatformWrapper>
+<PlatformWrapper platform={['ios','macos']}>
+<Vg k="AGORA_BACKEND" /> channels can be categorized into three types according to their usage and message delivery methods, namely **Message Channel**, **User Channel**, and **Stream Channel** which are distinguished by the `channelType` parameter in the API. The main differences between the three channel types are as follows:
+
+    - **Message Channel**: This channel type uses a common communication method that follows a publish-subscribe model to deliver messages, similar to the MQTT protocol. When using this model, there is no need to create a channel in advance, just publish messages to a specific channel or subscribe to a specific channel to receive messages. Due to its flexibility, users can easily implement different topologies such as one-to-one channels, group channels, broadcast channels, unicast channels, and so on. Because this channel type usually has a large number of subscribers, there is no guarantee that all subscribers will send delivery receipts when they receive a message.
+    - **User Channel**: This channel type is used to send peer-to-peer messages to a specified `userId`. When you use it, just set the `channelType` parameter in the `publish` method to `AgoraRtmChannelTypeUser` and the `channelName` parameter to the `userId` of the other party. You don't need to subscribe to receive messages, you just need to implement the `didReceiveMessageEvent` event listener. Because it is one-to-one message sending and receiving, this channel type supports the **delivery receipt** function. That is, after the sender sends a message, if the receiver is online and receives the message successfully, it will return `success`; if the receiver is not online or the reception fails, it will return `failure` or `timeout`. This channel type can only implement a one-to-one topology. Although you can judge whether the other party is online or not by the return value, we recommend using the `Presence` function for this.
+    - **Stream Channel**: This is a special type of channel that follows the room concept similar to the observer pattern. In this type of channel, users cannot send messages directly. User needs to call `joinTopic` method first to register as the publisher of the Topic before they can send messages. If the user wants to receive messages, they need to subscribe to the specified message publisher (identified by `userId`) in the specified Topic. In addition, client-side messages support delivery at higher QPS. This channel type is often recommended for meta-universe, parallel driving, and cloud gaming scenarios.
+
+In addition, `Presence`, `Storage`, and `Lock` functions can be enabled in both **Message Channel** and **Stream Channel** as needed. However, **User Channels** cannot utilize these features and can be treated as a simple message pass-through channel.
+</PlatformWrapper>
+
+<PlatformWrapper platform = 'web'>
+There are two types of channels in the <Vg k="AGORA_BACKEND" />, namely **Message** and **Stream**, which are distinguished in the API by `channelType`. The main differences between the two channel types are as follows:
+
+|Channel type |Main characteristics |Applicable scenarios |
+|:------------|:--------------------|:--------------------|
+|Message      |Following the industry-standard **Pub/Sub (publish/subscribe) model** to deliver messages and events, channels do not need to be created in advance and are available on demand. There is no cap (upper limit) on the number of publishers and subscribers in a channel, but there is a limit on the upstream QPS (queries per second) for a single channel. |Common applications based on pub/sub scenarios and multi-device access applications, such as multi-device management and command sending/receiving in the IoT industry, multi-terminal management and command sending/receiving location tracking in smart devices, large communities, and so on. |
+|Stream       |Following the room concept similar to the observer pattern in the industry, users need to join the channel in order to send and receive event notifications. Messages are managed and delivered via topics within the channel, and a single channel allows up to 1000 users to join at the same time. It supports co-channel and synchronous transmission of audio and video data with <Vg k="COMPANY" />. In addition, it also supports client-side message delivery with higher QPS. |High-frequency and high-concurrency data transmission scenarios as well as scenarios where <Vg k="COMPANY" /> audio and video data are synchronously transmitted in the same channel, for example, metaverse, parallel driving, cloud gaming, and so on. |
+
+A channel can be thought of as a conduit that controls the flow of messages. **Message** and **Stream** channels use different strategies for controlling the message flow:
+
+    - In a **Message Channel**, a publisher can simply deliver a message to a specific channel, and then any device or user subscribed to that channel can receive that message or event notification.
+    - In a **Stream Channel**, users cannot send messages directly. Users need to call `joinTopic` method to register as the publisher of the topic before they can send messages. If a user wants to receive messages, they need to subscribe to a specific message publisher (identified by user ID) in a given topic in order to receive the messages from that publisher.
+
+Except for messages, the mechanism and usage of **Message Channel** and **Stream Channel** for notification of other events such as **Presence**, **Storage**, **Lock**, and others are the same.
+</PlatformWrapper>
+<PlatformWrapper platform='unity'>
+There are two types of channels in the <Vg k="AGORA_BACKEND" />, namely **Message** and **Stream**, which are distinguished in the API by `RTM_CHANNEL_TYPE`. The main differences between the two channel types are as follows:
+
+|Channel type |Main characteristics |Applicable scenarios |
+|:------------|:--------------------|:--------------------|
+|Message      |Following the industry-standard pub/sub (publish/subscribe) model to deliver messages and events, channels do not need to be created in advance and are available on demand. There is no cap (upper limit) on the number of publishers and subscribers in a channel, but there is a limit on the upstream QPS (queries per second) for a single channel. |Common applications based on pub/sub scenarios and multi-device access applications, such as multi-device management and command sending/receiving in the IoT industry, multi-terminal management and command sending/receiving location tracking in smart devices, large communities, and so on. |
+|Stream       |Following the room concept similar to the observer pattern in the industry, users need to join the channel in order to send and receive event notifications. Messages are managed and delivered via topics within the channel, and a single channel allows up to 1000 users to join at the same time. It supports co-channel and synchronous transmission of audio and video data with <Vg k="COMPANY" />. In addition, it also supports client-side message delivery with higher QPS. |High-frequency and high-concurrency data transmission scenarios as well as scenarios where <Vg k="COMPANY" /> audio and video data are synchronously transmitted in the same channel, for example, metaverse, parallel driving, cloud gaming, and so on. |
+
+A channel can be thought of as a conduit that controls the flow of messages. **Message** and **Stream** channels use different strategies for controlling the message flow:
+
+    - In a **Message Channel**, a publisher can simply deliver a message to a specific channel, and then any device or user subscribed to that channel can receive that message or event notification.
+    - In a **Stream Channel**, users cannot send messages directly. Users need to call `JoinTopicAsync` method to register as the publisher of the topic before they can send messages. If a user wants to receive messages, they need to subscribe to a specific message publisher (identified by user ID) in a given topic in order to receive the messages from that publisher.
+
+Except for messages, the mechanism and usage of **Message Channel** and **Stream Channel** for notification of other events such as **Presence**, **Storage**, **Lock**, and others are the same.
+</PlatformWrapper>
+<PlatformWrapper platform='linux-cpp'>
+There are two types of channels in the <Vg k="AGORA_BACKEND" />, namely **Message** and **Stream**, which are distinguished in the API by `RTM_CHANNEL_TYPE`. The main differences between the two channel types are as follows:
+
+|Channel type |Main characteristics |Applicable scenarios |
+|:------------|:--------------------|:--------------------|
+|Message      |Following the industry-standard pub/sub (publish/subscribe) model to deliver messages and events, channels do not need to be created in advance and are available on demand. There is no cap (upper limit) on the number of publishers and subscribers in a channel, but there is a limit on the upstream QPS (queries per second) for a single channel. |Common applications based on pub/sub scenarios and multi-device access applications, such as multi-device management and command sending/receiving in the IoT industry, multi-terminal management and command sending/receiving location tracking in smart devices, large communities, and so on. |
+|Stream       |Following the room concept similar to the observer pattern in the industry, users need to join the channel in order to send and receive event notifications. Messages are managed and delivered via topics within the channel, and a single channel allows up to 1000 users to join at the same time. It supports co-channel and synchronous transmission of audio and video data with <Vg k="COMPANY" />. In addition, it also supports client-side message delivery with higher QPS. |High-frequency and high-concurrency data transmission scenarios as well as scenarios where <Vg k="COMPANY" /> audio and video data are synchronously transmitted in the same channel, for example, metaverse, parallel driving, cloud gaming, and so on. |
+
+A channel can be thought of as a conduit that controls the flow of messages. **Message** and **Stream** channels use different strategies for controlling the message flow:
+
+    - In a **Message Channel**, a publisher can simply deliver a message to a specific channel, and then any device or user subscribed to that channel can receive that message or event notification.
+    - In a **Stream Channel**, users cannot send messages directly. Users need to call `joinTopic` method to register as the publisher of the topic before they can send messages. If a user wants to receive messages, they need to subscribe to a specific message publisher (identified by user ID) in a given topic in order to receive the messages from that publisher.
+
+Except for messages, the mechanism and usage of **Message Channel** and **Stream Channel** for notification of other events such as **Presence**, **Storage**, **Lock**, and others are the same.
+</PlatformWrapper>
diff --git a/assets/code/signaling/channel-basics/create-channel.mdx b/assets/code/signaling/channel-basics/create-channel.mdx
@@ -0,0 +1,25 @@
+<PlatformWrapper platform='android'>
+For message channel, you do not need to define or create the channel in advance before using it. When you send a message to a message channel or subscribe to a message channel for the first time, <Vg k="AGORA_BACKEND" /> will automatically create the channel for you.
+
+For stream channel, although it is essentially ready to use, you need to explicitly call the `createStreamChannel` method to create an instance of a `StreamChannel` object before you can call the `join` method to join the channel.
+</PlatformWrapper>
+<PlatformWrapper platform={['ios','macos']}>
+For message channel, you do not need to define or create the channel in advance before using it. When you send a message to a message channel or subscribe to a message channel for the first time, <Vg k="AGORA_BACKEND" /> will automatically create the channel for you.
+
+For stream channel, although it is essentially ready to use, you need to explicitly call the `createStreamChannel` method to create an instance of a `AgoraRtmStreamChannel` object before you can call the `joinWithOption` method to join the channel.
+</PlatformWrapper>
+<PlatformWrapper platform = 'web'>
+For message channel, you do not need to define or create the channel in advance before using it. When you send a message to a message channel or subscribe to a message channel for the first time, <Vg k="AGORA_BACKEND" /> will automatically create the channel for you.
+
+For stream channel, although it is essentially ready to use, you need to explicitly call the `createStreamChannel` method to create an instance of a `RTMStreamChannel` object before you can call the `join` method to join the channel.
+</PlatformWrapper>
+<PlatformWrapper platform='unity'>
+For message channel, you do not need to define or create the channel in advance before using it. When you send a message to a message channel or subscribe to a message channel for the first time, <Vg k="AGORA_BACKEND" /> will automatically create the channel for you.
+
+For stream channel, although it is essentially ready to use, you need to explicitly call the `CreateStreamChannel` method to create an instance of a `IStreamChannel` object before you can call the `JoinAsync` method to join the channel.
+</PlatformWrapper>
+<PlatformWrapper platform='linux-cpp'>
+For message channel, you do not need to define or create the channel in advance before using it. When you send a message to a message channel or subscribe to a message channel for the first time, <Vg k="AGORA_BACKEND" /> will automatically create the channel for you.
+
+For stream channel, although it is essentially ready to use, you need to explicitly call the `createStreamChannel` method to create an instance of a `IStreamChannel` object before you can call the `join` method to join the channel.
+</PlatformWrapper>