Partager via

Canal de données

Remarque

Ce document décrit la fonctionnalité de canal de données présente dans le Kit de développement logiciel (SDK) d’appel Azure Communication Services. Bien que le canal de données dans ce contexte ressemble à celui du canal de données dans WebRTC, il est essentiel de reconnaître des différences subtiles dans leurs spécificités. Tout au long de ce document, nous utilisons des termes d’API ou d’API de canal de données pour désigner l’API de canal de données dans le Kit de développement logiciel (SDK). Lorsque vous faites référence à l’API de canal de données dans WebRTC, nous utilisons explicitement le terme API de canal de données WebRTC pour plus de clarté et de précision.

L’API de Canal de Données permet la messagerie en temps réel pendant les appels audio et vidéo. Avec cette API, vous pouvez désormais facilement intégrer des fonctionnalités d’échange de données dans les applications, ce qui offre une expérience de communication transparente pour les utilisateurs. Les principales fonctionnalités sont les suivantes :

  • Messagerie en temps réel : l’API de canal de données permet aux utilisateurs d’envoyer et de recevoir instantanément des messages pendant un appel audio ou vidéo en cours, en favorisant une communication fluide et efficace. Dans les scénarios d’appel de groupe, les messages peuvent être envoyés à un seul participant, à un ensemble spécifique de participants ou à tous les participants au sein de l’appel. Cette flexibilité améliore la communication et la collaboration entre les utilisateurs pendant les interactions de groupe.
  • Communication unidirectionnelle : contrairement à la communication bidirectionnelle, l’API Data Channel est conçue pour la communication unidirectionnelle. Il utilise des objets distincts pour l’envoi et la réception de messages : l’objet DataChannelSender pour l’envoi et l’objet DataChannelReceiver pour la réception. Cette séparation simplifie la gestion des messages dans les appels de groupe, ce qui entraîne une expérience utilisateur plus simplifiée.
  • Prise en charge des données binaires : l’API prend en charge l’envoi et la réception de données binaires, ce qui permet l’échange de différents types de données, tels que du texte, des images et des fichiers. Les messages texte doivent être sérialisés dans une mémoire tampon d’octets avant de pouvoir être transmis.
  • Options de l’expéditeur : l’API de canal de données fournit trois options configurables lors de la création d’un objet expéditeur, notamment la fiabilité, la priorité et le débit binaire. Ces options permettent à la configuration d’un canal de répondre à des besoins spécifiques pour différents cas d’usage.
  • Sécurité : tous les messages échangés entre un client et l’autre point de terminaison sont chiffrés, garantissant ainsi la confidentialité et la sécurité des données des utilisateurs.

Cas d’utilisation courants

Le canal de données peut être utilisé dans de nombreux scénarios différents. Deux exemples de cas d’usage courants sont les suivants :

Messagerie entre les participants dans un appel

L’API Canal de données permet la transmission de messages de type binaire entre les participants aux appels. Avec la sérialisation appropriée dans l’application, elle peut fournir différents types de messages à des fins différentes. Il existe également d’autres bibliothèques ou services fournissant les fonctionnalités de messagerie. Chacun d’entre eux présente ses avantages et ses inconvénients. Vous devez choisir celui qui convient à votre scénario d’utilisation. Par exemple, l’API De canal de données offre l’avantage de la communication à faible latence et simplifie la gestion des utilisateurs, car il n’est pas nécessaire de conserver une liste de participants distincte. Toutefois, la fonctionnalité de canal de données ne fournit pas de persistance des messages et ne garantit pas que le message ne sera pas perdu de bout en bout. Si vous avez besoin de la messagerie avec état ou de la remise garantie, vous pouvez envisager d’autres solutions.

Partage de fichiers

Le partage de fichiers représente un autre cas d’usage courant pour l’API du canal de données. Dans un scénario d’appel réseau pair à pair, la connexion de canal de données fonctionne sur une base de réseau pair à pair. Cette configuration offre une méthode efficace pour le transfert de fichiers, en tirant pleinement parti de la connexion directe et pair à pair pour améliorer la vitesse et réduire la latence.

Dans un scénario d’appel de groupe, les fichiers peuvent toujours être partagés entre les participants. Toutefois, il existe de meilleures façons, telles que stockage Azure ou Azure Files. En outre, la diffusion du contenu du fichier à tous les participants d’un appel peut être effectuée en définissant une liste de participants vide. Toutefois, il est important de garder à l’esprit qu’en plus des limitations de bande passante, il existe d’autres restrictions imposées lors d’un appel de groupe lors de la diffusion de messages, tels que le débit de paquets et la pression arrière de la vitesse de réception.

Concepts clés

Communication unidirectionnelle

L’API Data Channel est conçue pour la communication unidirectionnelle, par opposition à la communication bidirectionnelle dans le canal de données WebRTC. Il utilise des objets distincts pour l’envoi et la réception de messages, avec l’objet DataChannelSender responsable de l’envoi de messages et de l’objet DataChannelReceiver pour la réception de messages.

Le découplage des objets expéditeur et récepteur simplifie la gestion des messages dans les scénarios d’appel de groupe, ce qui offre une expérience plus simplifiée et conviviale.

Canal

Chaque message de canal de données est associé à un canal spécifique identifié par channelId. Il est important de clarifier que ce channelId n’est pas lié à la id propriété dans le canal de données WebRTC. Ce channelId peut être utilisé pour différencier différentes utilisations de l’application, telles que l’utilisation de 1000 pour les messages de contrôle et 1001 pour les transferts d’images.

Le channelId est affecté lors de la création d’un objet DataChannelSender et peut être spécifié par l’utilisateur ou déterminé par le Kit de développement logiciel (SDK) s’il n’est pas spécifié.

La plage valide d’un channelId se situe entre 1 et 65535. Si un channelId 0 est fourni ou si aucun channelId n’est fourni, le SDK affecte un channelId disponible à partir de la plage valide.

Fiabilité

Lors de la création, un canal peut être configuré pour être l’une des deux options de fiabilité : lossy ou durable.

Une chaîne lossy signifie que l’ordre des messages n’est pas garanti et qu’un message peut être supprimé sans notification lorsque l’envoi échoue. Il offre généralement une vitesse de transfert de données plus rapide.

Un durable canal signifie que le Kit de développement logiciel (SDK) garantit une remise de messages sans perte et ordonnée. Dans les cas où un message ne peut pas être remis, le Kit de développement logiciel (SDK) lève une exception. Dans le Kit de développement logiciel (SDK) Web, la durabilité du canal est assurée par le biais d’une connexion SCTP fiable. Toutefois, cela n'implique pas que le message ne soit pas perdu dans l'ensemble du processus. Dans le contexte d’un appel de groupe, cela signifie la prévention de la perte de messages entre l’expéditeur et le serveur. Dans un appel d’égal à égal, il indique une transmission fiable entre l’expéditeur et le point de terminaison distant.

Remarque

Dans l'implémentation actuelle du Kit de développement logiciel (SDK) Web, la transmission de données est effectuée via une connexion de canal de données WebRTC fiable pour les canaux lossy et durable.

Priorité

Lors de la création, un canal peut être configuré pour être l’une des deux options prioritaires : normal ou high.

Pour le Kit de développement logiciel (SDK) Web, les paramètres de priorité ne sont comparés qu’entre les canaux côté expéditeur. Les canaux avec une priorité high ont une priorité plus élevée pour la transmission par rapport à ceux avec une priorité normal.

Vitesse de transmission

Lors de la création d’un canal, une vitesse de transmission souhaitable peut être spécifiée pour l’allocation de bande passante.

Cette propriété de vitesse de transmission est de notifier le Kit de développement logiciel (SDK) de l’exigence de bande passante attendue pour un cas d’usage particulier. Bien que le SDK ne puisse généralement pas correspondre exactement au débit binaire, il essaie de répondre à la demande.

session

L'API du canal de données introduit le concept d'une session, qui respecte la sémantique d'ouverture-fermeture. Dans le Kit de développement logiciel (SDK), la session est associée à l’expéditeur ou à l’objet récepteur.

Lors de la création d’un objet expéditeur avec un nouvel id de canal, l’objet expéditeur est en état ouvert. Si l’API close() est appelée sur l’objet expéditeur, la session devient fermée et ne peut plus faciliter l’envoi de messages. En même temps, l’objet expéditeur avertit tous les participants de l’appel que la session est fermée.

Si un objet expéditeur est créé avec un channelId déjà existant, l’objet expéditeur existant associé à channelId est fermé et tous les messages envoyés à partir de l’objet expéditeur nouvellement créé sont reconnus dans le cadre de la nouvelle session.

Du point de vue du destinataire, les messages provenant de différentes sessions du côté de l’expéditeur sont dirigés vers des objets récepteur distincts. Si le Kit de développement logiciel (SDK) identifie une nouvelle session associée à un channelId existant côté récepteur, il crée un objet récepteur. Le Kit de développement logiciel (SDK) ne ferme pas l’ancien objet récepteur ; cette fermeture a lieu 1) lorsque l’objet récepteur reçoit une notification de fermeture de l’expéditeur, ou 2) si la session n’a reçu aucun message de l’expéditeur pendant plus de deux minutes.

Dans les cas où la session d’un objet récepteur est fermée et qu’aucune nouvelle session pour le même channelId n’existe côté récepteur, le SDK crée un objet récepteur lors de la réception d’un message à partir de la même session ultérieurement. Toutefois, si une nouvelle session pour le même channelId existe côté récepteur, le SDK ignore les messages entrants de la session précédente.

Étant donné que l’objet récepteur se ferme s’il ne reçoit pas de messages pendant plus de deux minutes, nous vous suggérons que l’application envoie régulièrement des messages de conservation actif du côté de l’expéditeur pour conserver l’état actif de l’objet récepteur.

Numéro de séquence

Le numéro de séquence est un entier non signé 32 bits inclus dans le message du canal de données pour indiquer l’ordre des messages au sein d’un canal. Il est important de noter que ce nombre est généré du point de vue de l’expéditeur. Par conséquent, un destinataire peut remarquer un écart dans les numéros de séquence si l’expéditeur modifie les destinataires lors de l’envoi de messages.

Par exemple, envisagez un scénario dans lequel un expéditeur envoie trois messages. Initialement, les destinataires sont le participant A et le participant B. Après le premier message, l’expéditeur change le destinataire au participant B et avant le troisième message, le destinataire est redirigé vers le participant A. Dans ce cas, le participant A reçoit deux messages avec des numéros de séquence 1 et 3. Toutefois, cela ne signifie pas une perte de message, mais reflète uniquement la modification des destinataires par l’expéditeur.

Limites

Taille des messages

La taille maximale autorisée d’un message unique est de 32 Ko. Si vous devez envoyer des données supérieures à la limite, vous devez diviser les données en plusieurs messages.

Liste des participants

Le nombre maximal de participants dans une liste est limité à 64. Si vous souhaitez spécifier d’autres participants, vous devez gérer la liste des participants par vous-même. Par exemple, si vous souhaitez envoyer un message à 50 participants, vous pouvez créer deux canaux différents, chacun avec 25 participants dans leurs listes de destinataires. Lors du calcul de la limite, deux points de terminaison avec le même identificateur de participant sont comptabilisés comme entités distinctes. En guise d’alternative, vous pouvez choisir de diffuser des messages. Toutefois, certaines restrictions s’appliquent lors de la diffusion de messages.

Limitation du débit

Actuellement, le SDK appelant a une limitation de débit implémentée, ce qui empêche les utilisateurs d’envoyer des données à une vitesse plus élevée même si leur réseau l’autorise. Les débits de bande passante actuels pour le canal de données sont les suivants :

  • Canal fiable (durable) : 64 Kbits/s
  • Canal non fiable (perte) : 512 kbits/s
  • Canal non fiable à priorité élevée : 200 kbit/s

Toutefois, lors de la diffusion de messages, la limite de vitesse de transmission est dynamique et dépend du débit de réception. Dans l’implémentation actuelle, la limite de débit d’envoi est calculée en tant que vitesse de transmission maximale moins 80% de la vitesse de transmission de réception.

En outre, nous appliquons également une restriction de débit de paquets lors de l’envoi de messages de diffusion. La limite actuelle est définie à 80 paquets par seconde, où tous les 1200 octets d’un message sont comptabilisés comme un paquet. Ces mesures sont en place pour prévenir les inondations lorsqu’un nombre important de participants à un appel de groupe diffusent des messages.

Étapes suivantes

Pour plus d’informations, consultez les articles suivants :