Freigeben über

Datenkanal

  • Artikel

Hinweis

Dieses Dokument befasst sich mit dem Feature „Datenkanal“ im Azure Communication Services Calling SDK. Während der Datenkanal in diesem Zusammenhang eine gewisse Ähnlichkeit mit dem Datenkanal in WebRTC hat, ist es wichtig, die feinen Unterschiede in ihren Besonderheiten zu erkennen. In diesem Dokument werden die Begriffe Datenkanal-API oder API verwendet, um die Datenkanal-API innerhalb des SDK zu bezeichnen. Wenn wir uns auf die Datenkanal-API in WebRTC beziehen, verwenden wir aus Gründen der Klarheit und Präzision ausdrücklich den Begriff WebRTC-Datenkanal-API.

Die Datenkanal-API ermöglicht Echtzeitmessaging während Audio- und Videoanrufen. Sie können mit dieser API jetzt ganz einfach Datenaustauschfunktionen in die Anwendungen integrieren und so Benutzern und Benutzerinnen eine nahtlose Kommunikationserfahrung bieten. Hauptfeatures sind:

  • Echtzeitmessaging: Mit der Datenkanal-API können Benutzer und Benutzerinnen Nachrichten während eines laufenden Audio- oder Videoanrufs sofort senden und empfangen. Dadurch wird eine reibungslose und effiziente Kommunikation gefördert. In Gruppenanrufszenarien können Nachrichten an einzelne Teilnehmer und Teilnehmerinnen, eine bestimmte Teilnehmergruppe oder alle Teilnehmer und Teilnehmerinnen des Anrufs gesendet werden. Diese Flexibilität verbessert die Kommunikation und Zusammenarbeit zwischen Benutzern und Benutzerinnen während Gruppeninteraktionen.
  • Unidirektionale Kommunikation:Die Datenkanal-API ist für die unidirektionale Kommunikation im Gegensatz zur bidirektionalen Kommunikation konzipiert. Es werden unterschiedliche Objekte zum Senden und Empfangen von Nachrichten eingesetzt: das DataChannelSender-Objekt zum Senden und das DataChannelReceiver-Objekt zum Empfangen. Diese Trennung vereinfacht die Nachrichtenverwaltung in Gruppenanrufen und führt zu einer optimierten Benutzererfahrung.
  • Unterstützung von Binärdaten: Die API unterstützt das Senden und Empfangen von Binärdaten, sodass verschiedene Datentypen ausgetauscht werden können, z. B. Text, Bilder und Dateien. Die Textnachrichten müssen in einen Bytepuffer serialisiert werden, bevor sie übertragen werden können.
  • Absenderoptionen: Die Datenkanal-API bietet beim Erstellen eines Absenderobjekts drei konfigurierbare Optionen, darunter Zuverlässigkeit, Priorität und Bitrate. Mit diesen Optionen kann ein Kanal so konfiguriert werden, dass er den spezifischen Anforderungen verschiedener Anwendungsfälle entspricht.
  • Sicherheit: Alle zwischen einem Client und dem anderen Endpunkt ausgetauschten Nachrichten werden verschlüsselt, wodurch der Datenschutz und die Sicherheit der Benutzerdaten gewährleistet werden.

Gängige Anwendungsfälle

Der Datenkanal kann in vielen verschiedenen Szenarien verwendet werden. Zwei gängige Beispiele für Anwendungsfälle sind:

Messaging zwischen Anrufteilnehmern

Die Datenkanal-API ermöglicht die Übertragung von binären Nachrichten zwischen Anrufteilnehmern. Mit der entsprechenden Serialisierung in der Anwendung kann sie verschiedene Nachrichtentypen für unterschiedliche Zwecke übermitteln. Es gibt auch andere Bibliotheken oder Dienste, die Messagingfunktionen bereitstellen. Alle haben jeweils Vor- und Nachteile. Sie sollten die für Ihr Verwendungsszenario geeigneten Bibliotheken oder Dienste auswählen. Beispielsweise bietet die Datenkanal-API den Vorteil einer Kommunikation mit geringer Latenz und vereinfacht die Benutzerverwaltung, da keine separate Teilnehmerliste verwaltet werden muss. Das Datenkanalfeature bietet jedoch keine Persistenz von Nachrichten und garantiert nicht, dass eine Nachricht nicht durchgehend verloren geht. Wenn Sie zustandsbehaftetes Messaging oder eine garantierte Zustellung benötigen, sollten Sie alternative Lösungen in Betracht ziehen.

Dateifreigabe

Die Dateifreigabe stellt einen weiteren häufigen Anwendungsfall für die Datenkanal-API dar. In einem Peer-zu-Peer-Anrufszenario funktioniert die Datenkanalverbindung auf Peer-zu-Peer-Basis. Dieses Setup bietet eine effiziente Methode für die Dateiübertragung, wobei die direkte Peer-zu-Peer-Verbindung vollständig genutzt wird, um die Geschwindigkeit zu erhöhen und die Latenz zu verringern.

In einem Gruppenanrufszenario können Dateien weiterhin für Teilnehmer und Teilnehmerinnen freigegeben werden. Es gibt jedoch bessere Möglichkeiten, z. B. Azure Storage oder Azure Files. Außerdem kann der Dateiinhalt an alle Teilnehmer und Teilnehmerinnen eines Anrufs gesendet werden, indem eine leere Teilnehmerliste festgelegt wird. Es ist jedoch unbedingt zu beachten, dass es während eines Gruppenanrufs neben den Bandbreitenbeschränkungen weitere Beschränkungen bei der Übertragung von Nachrichten gibt, z. B. die Paketrate und der Gegendruck durch die Empfangsbitrate.

Wichtige Begriffe

Unidirektionale Kommunikation

Die Datenkanal-API ist für die unidirektionale Kommunikation konzipiert, im Gegensatz zur bidirektionalen Kommunikation im WebRTC-Datenkanal. Sie verwendet separate Objekte zum Senden und Empfangen von Nachrichten, wobei das DataChannelSender-Objekt für das Senden von Nachrichten und das DataChannelReceiver-Objekt für das Empfangen von Nachrichten verantwortlich ist.

Die Entkopplung der Absender- und Empfängerobjekte vereinfacht die Nachrichtenverarbeitung in Gruppenanrufszenarien und bietet eine optimierte und benutzerfreundlichere Erfahrung.

Kanal

Jede Datenkanalnachricht ist einem bestimmten Kanal zugeordnet, der durch channelId identifiziert wird. Es muss klargestellt werden, dass diese channelId nicht mit der Eigenschaft id im WebRTC-Datenkanal zusammenhängt. Diese channelId kann verwendet werden, um verschiedene Anwendungszwecke zu unterscheiden, z. B. die Verwendung von 1000 für Steuerungsnachrichten und 1001 für Bildübertragungen.

Die channelId wird während der Erstellung eines DataChannelSender-Objekts zugewiesen und kann entweder vom Benutzer bzw. der Benutzerin angegeben oder vom SDK festgelegt werden, wenn die Angabe fehlt.

Der gültige Wertebereich einer channelId liegt zwischen 1 und 65535. Wenn die channelId 0 oder keine channelId bereitgestellt wird, weist das SDK eine verfügbare channelId aus dem gültigen Bereich zu.

Zuverlässigkeit

Nach der Erstellung kann ein Kanal mit einer der beiden Zuverlässigkeitsoptionen konfiguriert werden: lossy oder durable.

Ein lossy-Kanal bedeutet, dass die Reihenfolge der Nachrichten nicht garantiert ist und eine Nachricht stillschweigend gelöscht werden kann, wenn das Senden fehlschlägt. Er bietet in der Regel eine höhere Datenübertragungsgeschwindigkeit.

Ein durable-Kanal bedeutet, dass das SDK eine verlustfreie und geordnete Nachrichtenzustellung garantiert. In Fällen, in denen eine Nachricht nicht übermittelt werden kann, löst das SDK eine Ausnahme aus. Im Web SDK wird die Dauerhaftigkeit des Kanals durch eine zuverlässige SCTP-Verbindung sichergestellt. Das bedeutet jedoch nicht, dass die Nachricht nicht durchgehend verloren gehen kann. Im Kontext eines Gruppenaufrufs bedeutet dies, dass Nachrichtenverluste zwischen dem Absender und dem Server verhindert werden. In einem Peer-zu-Peer-Anruf hat es eine zuverlässige Übertragung zwischen dem Absender und dem Remoteendpunkt zur Folge.

Hinweis

In der aktuellen Web SDK-Implementierung erfolgt die Datenübertragung sowohl für den Kanal lossy als auch für den Kanal durable über eine zuverlässige WebRTC-Datenkanalverbindung.

Priorität

Nach der Erstellung kann ein Kanal mit einer der beiden Prioritätsoptionen konfiguriert werden: normal oder high.

Beim Web SDK werden Prioritätseinstellungen nur zwischen Kanälen auf der Absenderseite verglichen. Kanäle mit der Priorität high erhalten bei der Übertagung eine höhere Priorität als Kanäle mit der Priorität normal.

Bitrate

Beim Erstellen eines Kanals kann eine gewünschte Bitrate für die Bandbreitenzuweisung angegeben werden.

Diese Bitrate-Eigenschaft soll das SDK über die erwartete Bandbreitenanforderung für einen bestimmten Anwendungsfall benachrichtigen. Obwohl das SDK im Allgemeinen dieser Anforderung an die Bitrate nicht genau entsprechen kann, versucht es, sie zu erfüllen.

Sitzung

Die Datenkanal-API führt das Konzept einer Sitzung ein, die der Öffnen-Schließen-Semantik entspricht. Im SDK wird die Sitzung dem Absender- oder dem Empfängerobjekt zugeordnet.

Beim Erstellen eines Absenderobjekts mit einer neuen channelId befindet sich das Absenderobjekt im geöffneten Zustand. Wenn die close()-API für das Absenderobjekt aufgerufen wird, wird die Sitzung geschlossen. Dann kann sie das Senden von Nachrichten nicht mehr vereinfachen. Gleichzeitig benachrichtigt das Absenderobjekt alle Anrufteilnehmer und -teilnehmerinnen, dass die Sitzung geschlossen worden ist.

Wenn ein Absenderobjekt mit einer bereits vorhandenen channelId erstellt wird, wird das vorhandene, der channelId zugeordnete Absenderobjekt geschlossen, und alle Nachrichten, die vom neu erstellten Absenderobjekt gesendet werden, werden als Teil der neuen Sitzung erkannt.

Aus Sicht des Empfängers werden Nachrichten, die aus verschiedenen Sitzungen auf der Seite des Absenders stammen, an unterschiedliche Empfängerobjekte geleitet. Wenn das SDK eine neue Sitzung identifiziert, die einer vorhandenen channelId auf der Empfängerseite zugeordnet ist, wird ein neues Empfängerobjekt erstellt. Das SDK schließt das ältere Empfängerobjekt nicht. Diese Schließung erfolgt, 1) wenn das Empfängerobjekt eine Schließungsbenachrichtigung vom Absender empfängt oder 2) wenn in der Sitzung seit mehr als zwei Minuten keine Nachrichten vom Absender empfangen wurden.

In Fällen, in denen die Sitzung eines Empfängerobjekts geschlossen wird und keine neue Sitzung für dieselbe channelId auf der Empfängerseite vorhanden ist, erstellt das SDK ein neues Empfängerobjekt, wenn zu einem späteren Zeitpunkt eine Nachricht aus derselben Sitzung eingeht. Wenn jedoch auf der Empfängerseite eine neue Sitzung für dieselbe channelId vorhanden ist, verwirft das SDK alle eingehenden Nachrichten aus der vorherigen Sitzung.

In Anbetracht der Tatsache, dass das Empfängerobjekt geschlossen wird, wenn es länger als zwei Minuten keine Nachrichten empfängt, wird empfohlen, dass die Anwendung regelmäßig Keep-Alive-Nachrichten von der Absenderseite aus sendet, um den aktiven Status des Empfängerobjekts aufrechtzuerhalten.

Sequenznummer

Die Sequenznummer ist eine 32 Bit umfassende ganze Ganzzahl ohne Vorzeichen, die in der Datenkanalnachricht enthalten ist, um die Reihenfolge von Nachrichten in einem Kanal anzugeben. Es ist wichtig zu wissen, dass diese Zahl aus der Perspektive der Absenderseite generiert wird. Folglich kann das Empfängerobjekt eine Lücke in den Sequenznummern feststellen, wenn das Absenderobjekt die Empfängerobjekte während des Sendens von Nachrichten ändert.

Betrachten Sie beispielsweise ein Szenario, in dem ein Absenderobjekt drei Nachrichten sendet. Zunächst sind Teilnehmer A und Teilnehmer B die Empfänger. Nach der ersten Nachricht ändert der Absender den Empfänger in Teilnehmer B, und vor der dritten Nachricht wird der Empfänger in Teilnehmer A geändert. In diesem Fall empfängt Teilnehmer A zwei Nachrichten mit Sequenznummern 1 und 3. Dies bedeutet jedoch nicht, dass Nachrichten verloren gehen, sondern spiegelt nur die Änderung der Empfänger durch den Absender wider.

Begrenzungen

Nachrichtengröße

Die maximal zulässige Größe für eine einzelne Nachricht beträgt 32 KB. Wenn Sie Daten senden müssen, die größer als dieser Grenzwert sind, müssen Sie die Daten in mehrere Nachrichten aufteilen.

Teilnehmerliste

Die maximale Teilnehmeranzahl in einer Liste ist auf 64 begrenzt. Wenn Sie weitere Teilnehmer oder Teilnehmerinnen angeben möchten, müssen Sie die Teilnehmerliste selbst verwalten. Wenn Sie beispielsweise eine Nachricht an 50 Teilnehmer und Teilnehmerinnen senden möchten, können Sie zwei verschiedene Kanäle erstellen, die jeweils 25 Teilnehmer und Teilnehmerinnen in ihren Empfängerlisten enthalten. Bei der Berechnung des Grenzwerts werden zwei Endpunkte mit demselben Teilnehmerbezeichner als separate Entitäten gezählt. Alternativ können Sie sich für das Übertragen von Nachrichten entscheiden. Beim Übertragen von Nachrichten gelten jedoch bestimmte Einschränkungen.

Ratenbegrenzung

Derzeit ist im Anruf-SDK eine Ratenbegrenzung implementiert. Sie verhindert, dass Benutzer und Benutzerinnen Daten mit einer höheren Geschwindigkeit senden, selbst wenn ihr Netzwerk dies zulassen würde. Die aktuellen Bandbreitenraten-Höchstwerte für Datenkanal sind:

  • Zuverlässiger Kanal (Durable): 64 KBit/s
  • Unzuverlässiger Kanal (Lossy): 512 KBit/s
  • Unzuverlässiger Kanal mit hoher Priorität: 200 KBit/s

Wenn Nachrichten übertragen werden, ist die Bitratenbegrenzung jedoch dynamisch und hängt von der Empfangsbitrate ab. In der aktuellen Implementierung wird der Grenzwert für die Sendebitrate als maximale Sendebitrate minus 80 % der Empfangsbitrate berechnet.

Überdies wird beim Senden von Übertragungsnachrichten eine Paketrateneinschränkung erzwungen. Der aktuelle Grenzwert beträgt 80 Pakete pro Sekunde, wobei jeweils 1200 Bytes einer Nachricht als ein Paket gezählt werden. Diese Maßnahmen sind vorhanden, um eine Nachrichtenüberflutung zu verhindern, wenn eine große Anzahl von Teilnehmern und Teilnehmerinnen in einem Gruppenanruf Nachrichten sendet.

Nächste Schritte

Weitere Informationen finden Sie in den folgenden Artikeln: