Freigeben über

Datenkanal

Hinweis

Dieses Dokument befasst sich mit dem Feature "Datenkanal", das im Azure Communication Services Calling SDK vorhanden ist. Während der Datenkanal in diesem Zusammenhang einige Ähnlichkeiten mit dem Datenkanal in WebRTC aufweist, ist es entscheidend, subtile Unterschiede in ihren Besonderheiten zu erkennen. In diesem Dokument verwenden wir Begriffe Data Channel API oder API , um die Datenkanal-API innerhalb des SDK zu kennzeichnen. Wenn wir auf die Datenkanal-API in WebRTC verweisen, verwenden wir explizit den Begriff WebRTC Data Channel API für Klarheit und Genauigkeit.

Die Datenkanal-API ermöglicht Echtzeitnachrichten während Audio- und Videoanrufen. Mit dieser API können Sie jetzt ganz einfach Datenaustauschfunktionen in die Anwendungen integrieren, was eine nahtlose Kommunikationserfahrung für Benutzer bietet. Zu den wichtigsten Features gehören:

  • Echtzeitnachrichten: Mit der Datenkanal-API können Benutzer Nachrichten während eines laufenden Audio- oder Videoanrufs sofort senden und empfangen, wodurch eine reibungslose und effiziente Kommunikation gefördert wird. In Gruppenanrufszenarien können Nachrichten an einen einzelnen Teilnehmer, eine bestimmte Gruppe von Teilnehmern oder alle Teilnehmer innerhalb des Anrufs gesendet werden. Diese Flexibilität verbessert die Kommunikation und Zusammenarbeit zwischen Benutzern und Benutzerinnen während Gruppeninteraktionen.
  • Unidirektionale Kommunikation: Im Gegensatz zur bidirektionalen Kommunikation ist die Data Channel-API für unidirektionale Kommunikation konzipiert. Es verwendet unterschiedliche Objekte zum Senden und Empfangen von Nachrichten: das DataChannelSender -Objekt zum Senden und das DataChannelReceiver -Objekt für den Empfang. Diese Trennung vereinfacht die Nachrichtenverwaltung in Gruppenanrufen, was zu einer optimierteren Benutzererfahrung führt.
  • Unterstützung von Binärdaten: Die API unterstützt das Senden und Empfangen von Binärdaten, was den Austausch verschiedener Datentypen ermöglicht, 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 drei konfigurierbare Optionen beim Erstellen eines Absenderobjekts, einschließlich Zuverlässigkeit, Priorität und Bitrate. Diese Optionen ermöglichen die Konfiguration eines Kanals, um bestimmte Anforderungen für unterschiedliche Anwendungsfälle zu erfüllen.
  • Sicherheit: Alle zwischen einem Client und dem anderen Endpunkt ausgetauschten Nachrichten werden verschlüsselt, wodurch der Datenschutz und die Sicherheit der Benutzerdaten sichergestellt werden.

Gängige Anwendungsfälle

Der Datenkanal kann in vielen verschiedenen Szenarien verwendet werden. Zwei gängige Anwendungsfallbeispiele sind:

Messaging zwischen Teilnehmern während eines Anrufs

Die Datenkanal-API ermöglicht die Übertragung binärer 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 die Messagingfunktionen bereitstellen. Jeder von ihnen hat seine Vor- und Nachteile. Sie sollten den geeigneten für Ihr Nutzungsszenario auswählen. Beispielsweise bietet die Datenkanal-API den Vorteil der 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 verbessern und die Latenz zu verringern.

In einem Gruppenanrufszenario können Dateien weiterhin für Teilnehmer freigegeben werden. Es gibt jedoch bessere Möglichkeiten, z. B. Azure Storage oder Azure Files. Darüber hinaus kann das Übertragen des Dateiinhalts an alle Teilnehmer eines Anrufs durch Festlegen einer leeren Teilnehmerliste erreicht werden. Es ist jedoch wichtig zu beachten, dass neben Bandbreiteneinschränkungen weitere Einschränkungen während eines Gruppenanrufs beim Übertragen von Nachrichten, z. B. Paketrate und Rückdruck von der Empfangsbitrate, auferlegt werden.

Wichtige Begriffe

Unidirektionale Kommunikation

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

Die Entkopplung von Absender- und Empfängerobjekten vereinfacht die Nachrichtenverarbeitung in Gruppenanrufszenarien und bietet eine optimierte und benutzerfreundlichere Benutzererfahrung.

Kanal

Jede Nachricht des Datenkanals ist einem bestimmten Kanal zugeordnet, der durch channelId identifiziert wird. Es ist wichtig zu verdeutlichen, dass diese channelId nicht mit der id Eigenschaft im WebRTC-Datenkanal verknüpft ist. Diese channelId kann verwendet werden, um verschiedene Anwendungsverwendungen zu unterscheiden, z. B. 1000 zum Steuern von Nachrichten und 1001 für Bildübertragungen.

Die channelId wird bei der Erstellung eines DataChannelSender-Objekts zugewiesen und kann entweder vom Benutzer angegeben oder vom SDK bestimmt werden, falls sie nicht festgelegt ist.

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

Zuverlässigkeit

Bei der Erstellung kann ein Kanal so konfiguriert werden, dass er eine der beiden Zuverlässigkeitsoptionen ist: lossy oder durable.

Ein lossy Kanal bedeutet, dass die Reihenfolge der Nachrichten nicht garantiert ist und eine Nachricht im Hintergrund gelöscht werden kann, wenn das Senden fehlschlägt. Es bietet in der Regel eine schnellere Datenübertragungsgeschwindigkeit.

Ein durable Kanal bedeutet, dass das SDK eine verlustfreie und geordnete Nachrichtenübermittlung garantiert. In Fällen, in denen eine Nachricht nicht übermittelt werden kann, löst das SDK eine Ausnahme aus. Im Web SDK wird die Haltbarkeit 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 die Verhinderung von Nachrichtenverlusten zwischen dem Absender und dem Server. Bei einem Peer-to-Peer-Anruf bedeutet dies eine zuverlässige Übertragung zwischen dem Absender und dem Remoteendpunkt.

Hinweis

In der aktuellen Web SDK-Implementierung erfolgt die Datenübertragung über eine zuverlässige WebRTC Data Channel-Verbindung für beide lossy und durable Kanäle.

Priorität

Bei der Erstellung kann ein Kanal so konfiguriert werden, dass er eine der beiden Prioritätsoptionen ist: normal oder high.

Für das Web SDK werden Prioritätseinstellungen nur zwischen Kanälen auf der Absenderseite verglichen. Kanäle mit einer high Priorität erhalten eine höhere Priorität für die Übertragung im Vergleich zu den Kanälen mit normal Priorität.

Datenrate

Beim Erstellen eines Kanals kann eine wünschenswerte Bitrate für die Bandbreitenzuweisung angegeben werden.

Diese Bitrate-Eigenschaft besteht darin, das SDK über die erwartete Bandbreitenanforderung für einen bestimmten Anwendungsfall zu benachrichtigen. Obwohl das SDK im Allgemeinen nicht mit der genauen Bitrate übereinstimmen kann, versucht es, die Anforderung aufzunehmen.

Sitzung

Die Datenkanal-API führt das Konzept einer Sitzung ein, die der open-close-Semantik entspricht. Im SDK ist 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 und kann das Senden von Nachrichten nicht mehr vereinfachen. Gleichzeitig benachrichtigt das Absenderobjekt alle Teilnehmer am Anruf, dass die Sitzung geschlossen ist.

Wenn ein Absenderobjekt mit einer bereits vorhandenen channelId erstellt wird, wird das vorhandene Absenderobjekt, das der channelId zugeordnet ist, 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 von 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 Seite des Empfängers 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 die Sitzung keine Nachrichten des Absenders für mehr als zwei Minuten empfangen hat.

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 nach Erhalt einer Nachricht aus derselben Sitzung zu einem späteren Zeitpunkt. Wenn jedoch eine neue Sitzung für dieselbe channelId auf der Empfängerseite vorhanden ist, verwirft das SDK alle eingehenden Nachrichten aus der vorherigen Sitzung.

Wenn das Empfängerobjekt geschlossen wird, wenn es keine Nachrichten für mehr als zwei Minuten empfängt, empfehlen wir, dass die Anwendung regelmäßig Keep-Alive-Nachrichten von der Absenderseite sendet, um den aktiven Status des Empfängerobjekts beizubehalten.

Sequenznummer

Die Sequenznummer ist eine 32-Bit-ganzzahl ohne Vorzeichen, die in der Datenkanalnachricht enthalten ist, um die Reihenfolge von Nachrichten in einem Kanal anzugeben. Es ist wichtig zu beachten, dass diese Nummer aus der Perspektive des Absenders generiert wird. Folglich kann ein Empfänger eine Lücke in den Sequenznummern feststellen, wenn der Absender die Empfänger während des Sendens von Nachrichten ändert.

Ziehen Sie beispielsweise ein Szenario in Betracht, in dem ein Absender drei Nachrichten sendet. Zunächst sind die Empfänger Teilnehmer A und Teilnehmer B. Nach der ersten Nachricht ändert der Absender den Empfänger in Teilnehmer B, und vor der dritten Nachricht wird der Empfänger zu Teilnehmer A gewechselt. In diesem Fall empfängt Teilnehmer A zwei Nachrichten mit Sequenznummern 1 und 3. Dies bedeutet jedoch nicht, dass ein Nachrichtenverlust auftritt, sondern nur, dass der Absender die Empfänger geändert hat.

Einschränkungen

Nachrichtengröße

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

Teilnehmerliste

Die maximale Anzahl von Teilnehmern in einer Liste ist auf 64 beschränkt. Wenn Sie weitere Teilnehmer angeben möchten, müssen Sie die Teilnehmerliste selbst verwalten. Wenn Sie beispielsweise eine Nachricht an 50 Teilnehmer senden möchten, können Sie zwei verschiedene Kanäle erstellen, die jeweils 25 Teilnehmer 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 die Übertragung von Nachrichten entscheiden. Beim Übertragen von Nachrichten gelten jedoch bestimmte Einschränkungen.

Ratenbegrenzung

Derzeit hat das aufrufende SDK eine Datenübertragungsbegrenzung implementiert, die verhindert, dass Benutzer Daten mit höherer Geschwindigkeit senden, selbst wenn ihr Netzwerk dies zulässt. Die aktuellen Bandbreitenraten-Höchstwerte für datenkanal sind:

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

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

Darüber hinaus erzwingen wir beim Senden von Übertragungsnachrichten eine Paketrateneinschränkung. Der aktuelle Grenzwert wird auf 80 Pakete pro Sekunde festgelegt, wobei alle 1200 Bytes in einer Nachricht als ein Paket gezählt werden. Diese Maßnahmen sind vorhanden, um Überschwemmungen zu verhindern, wenn eine erhebliche Anzahl von Teilnehmern in einem Gruppenanruf Nachrichten sendet.

Nächste Schritte

Weitere Informationen finden Sie in den folgenden Artikeln: