Delen via

Gegevenskanaal

  • Artikel

Notitie

In dit document wordt dieper ingegaan op de datakanaalfunctie die aanwezig is in de Aanroepende SDK van Azure Communication Services. Hoewel het gegevenskanaal in deze context lijkt op het gegevenskanaal in WebRTC, is het van cruciaal belang om subtiele verschillen in hun specifieke gegevens te herkennen. In dit document gebruiken we termen Data Channel-API of API om de Data Channel-API binnen de SDK aan te geven. Wanneer we verwijzen naar de Data Channel-API in WebRTC, gebruiken we expliciet de term WebRTC Data Channel-API voor duidelijkheid en precisie.

De Data Channel-API maakt realtimeberichten mogelijk tijdens audio- en videogesprekken. Met deze API kunt u nu eenvoudig functies voor gegevensuitwisseling integreren in de toepassingen, zodat gebruikers naadloos kunnen communiceren. Belangrijke functies omvatten onder meer:

  • Realtime berichten: met de Data Channel-API kunnen gebruikers direct berichten verzenden en ontvangen tijdens een doorlopende audio- of videogesprek, waardoor soepele en efficiënte communicatie wordt bevorderd. In groepsoproepscenario's kunnen berichten worden verzonden naar één deelnemer, een specifieke set deelnemers of alle deelnemers in het gesprek. Deze flexibiliteit verbetert de communicatie en samenwerking tussen gebruikers tijdens groepsinteracties.
  • Unidirectionele communicatie: in tegenstelling tot bidirectionele communicatie is de Data Channel-API ontworpen voor unidirectionele communicatie. Het maakt gebruik van afzonderlijke objecten voor het verzenden en ontvangen van berichten: het DataChannelSender-object voor verzenden en het DataChannelReceiver-object voor ontvangst. Deze scheiding vereenvoudigt het beheer van berichten in groepsgesprekken, wat leidt tot een meer gestroomlijnde gebruikerservaring.
  • Ondersteuning voor binaire gegevens: de API ondersteunt het verzenden en ontvangen van binaire gegevens, waardoor verschillende gegevenstypen kunnen worden uitgewisseld, zoals tekst, afbeeldingen en bestanden. De tekstberichten moeten worden geserialiseerd in een bytebuffer voordat ze kunnen worden verzonden.
  • Opties voor afzender: de Data Channel-API biedt drie configureerbare opties bij het maken van een afzenderobject, waaronder betrouwbaarheid, prioriteit en bitrate. Met deze opties kan de configuratie van een kanaal voldoen aan specifieke behoeften voor verschillende use cases.
  • Beveiliging: alle berichten die worden uitgewisseld tussen een client en het andere eindpunt worden versleuteld, waardoor de privacy en beveiliging van de gegevens van gebruikers worden gewaarborgd.

Veelvoorkomende toepassingen

Het gegevenskanaal kan in veel verschillende scenario's worden gebruikt. Twee veelvoorkomende use-casevoorbeelden zijn:

Berichten tussen deelnemers in een gesprek

De Data Channel-API maakt het verzenden van binaire type berichten tussen oproepdeelnemers mogelijk. Met de juiste serialisatie in de toepassing kan het verschillende berichttypen voor verschillende doeleinden leveren. Er zijn ook andere bibliotheken of services die de berichtenfunctionaliteit bieden. Elk van hen heeft zijn voor- en nadelen. Kies de geschikte optie voor uw gebruiksscenario. De Data Channel-API biedt bijvoorbeeld het voordeel van communicatie met lage latentie en vereenvoudigt gebruikersbeheer omdat er geen afzonderlijke lijst met deelnemers hoeft te worden onderhouden. De gegevenskanaalfunctie biedt echter geen berichtpersistentie en garandeert niet dat het bericht op een end-to-end manier verloren gaat. Als u stateful berichten of gegarandeerde levering nodig hebt, kunt u alternatieve oplossingen overwegen.

Bestanden delen

Het delen van bestanden vertegenwoordigt nog een veelvoorkomende use cases voor de Data Channel-API. In een peer-to-peer-gespreksscenario werkt de Data Channel-verbinding op peer-to-peerbasis. Deze installatie biedt een efficiënte methode voor bestandsoverdracht, waarbij de directe peer-to-peerverbinding optimaal wordt benut om de snelheid te verbeteren en de latentie te verminderen.

In een groepsoproepscenario kunnen bestanden nog steeds worden gedeeld tussen deelnemers. Er zijn echter betere manieren, zoals Azure Storage of Azure Files. Daarnaast kan het uitzenden van de bestandsinhoud aan alle deelnemers aan een gesprek worden bereikt door een lege lijst met deelnemers in te stellen. Het is echter belangrijk om er rekening mee te houden dat er, naast bandbreedtebeperkingen, verdere beperkingen worden opgelegd tijdens een groepsgesprek bij het uitzenden van berichten, zoals pakketsnelheid en backdruk van de ontvangstbitrate.

Belangrijke concepten

Unidirectionele communicatie

De Data Channel-API is ontworpen voor unidirectionele communicatie, in tegenstelling tot bidirectionele communicatie in WebRTC Data Channel. Het maakt gebruik van afzonderlijke objecten voor het verzenden en ontvangen van berichten, met DataChannelSender-object dat verantwoordelijk is voor het verzenden van berichten en het DataChannelReceiver-object voor het ontvangen van berichten.

De ontkoppeling van afzender- en ontvangerobjecten vereenvoudigt de verwerking van berichten in groepsoproepscenario's en biedt een gestroomlijndere en gebruiksvriendelijkere ervaring.

Channel

Elk gegevenskanaalbericht is gekoppeld aan een specifiek kanaal dat wordt geïdentificeerd door channelId. Het is belangrijk om te verduidelijken dat deze channelId niet is gerelateerd aan de id eigenschap in het WebRTC-gegevenskanaal. Deze channelId kan worden gebruikt om verschillende toepassingen te onderscheiden, zoals het gebruik van 1000 voor controleberichten en 1001 voor afbeeldingsoverdrachten.

De channelId wordt toegewezen tijdens het maken van een DataChannelSender-object en kan door de gebruiker worden opgegeven of worden bepaald door de SDK als deze niet is opgegeven.

Het geldige bereik van een channelId ligt tussen 1 en 65535. Als er een channelId 0 is opgegeven of als er geen channelId is opgegeven, wijst de SDK een beschikbare channelId toe vanuit het geldige bereik.

Betrouwbaarheid

Bij het maken kan een kanaal worden geconfigureerd als een van de twee betrouwbaarheidsopties: lossy of durable.

Een lossy kanaal betekent dat de volgorde van berichten niet gegarandeerd is en dat een bericht op de achtergrond kan worden verwijderd wanneer het verzenden mislukt. Het biedt over het algemeen een snellere snelheid van gegevensoverdracht.

Een durable kanaal betekent dat de SDK een verliesloze en geordende berichtbezorging garandeert. In gevallen waarin een bericht niet kan worden bezorgd, genereert de SDK een uitzondering. In de Web SDK wordt de duurzaamheid van het kanaal gegarandeerd via een betrouwbare SCTP-verbinding. Het betekent echter niet dat het bericht niet op een end-to-end manier verloren gaat. In de context van een groepsoproep wordt de preventie van berichtverlies tussen de afzender en de server opgegeven. In een peer-to-peer-aanroep wordt een betrouwbare overdracht tussen de afzender en het externe eindpunt aangeduid.

Notitie

In de huidige web-SDK-implementatie wordt gegevensoverdracht uitgevoerd via een betrouwbare WebRTC-gegevenskanaalverbinding voor zowel als lossy durable kanalen.

Prioriteit

Bij het maken kan een kanaal worden geconfigureerd als een van de twee prioriteitsopties: normal of high.

Voor de Web-SDK worden prioriteitsinstellingen alleen vergeleken tussen kanalen aan de kant van de afzender. Kanalen met een high prioriteit krijgen een hogere prioriteit voor verzending in vergelijking met de kanalen met normal prioriteit.

Bitrate

Bij het maken van een kanaal kan een gewenste bitrate worden opgegeven voor bandbreedtetoewijzing.

Deze bitrate-eigenschap is om de SDK op de hoogte te stellen van de verwachte bandbreedtevereiste voor een bepaalde use-case. Hoewel de SDK over het algemeen niet overeenkomt met de exacte bitrate, wordt geprobeerd de aanvraag te verwerken.

Sessie

De Data Channel-API introduceert het concept van een sessie, die voldoet aan open-close-semantiek. In de SDK is de sessie gekoppeld aan de afzender of het ontvangerobject.

Bij het maken van een afzenderobject met een nieuwe channelId heeft het afzenderobject de status Open. Als de close() API wordt aangeroepen op het afzenderobject, wordt de sessie gesloten en kan het verzenden van berichten niet meer worden vereenvoudigd. Tegelijkertijd meldt het afzenderobject alle deelnemers aan het gesprek dat de sessie is gesloten.

Als een afzenderobject wordt gemaakt met een al bestaande channelId, wordt het bestaande afzenderobject dat is gekoppeld aan de channelId gesloten en worden alle berichten die zijn verzonden vanaf het zojuist gemaakte afzenderobject herkend als onderdeel van de nieuwe sessie.

Vanuit het perspectief van de ontvanger worden berichten die afkomstig zijn van verschillende sessies aan de kant van de afzender omgeleid naar afzonderlijke ontvangerobjecten. Als de SDK een nieuwe sessie identificeert die is gekoppeld aan een bestaande channelId aan de zijde van de ontvanger, wordt er een nieuw ontvangerobject gemaakt. De SDK sluit het oudere ontvangerobject niet; een dergelijke sluiting vindt plaats 1) wanneer het ontvangerobject een sluitingsmelding van de afzender ontvangt, of 2) als de sessie meer dan twee minuten geen berichten van de afzender heeft ontvangen.

In gevallen waarin de sessie van een ontvangerobject wordt gesloten en er geen nieuwe sessie voor dezelfde channelId bestaat aan de zijde van de ontvanger, maakt de SDK een nieuw ontvangerobject na ontvangst van een bericht van dezelfde sessie op een later tijdstip. Als er echter een nieuwe sessie voor dezelfde channelId bestaat aan de zijde van de ontvanger, worden alle binnenkomende berichten van de vorige sessie verwijderd door de SDK.

Gezien het feit dat het ontvangerobject wordt gesloten als het meer dan twee minuten geen berichten ontvangt, raden we aan dat de toepassing periodiek keep-alive-berichten verzendt van de kant van de afzender om de actieve status van het ontvangerobject te behouden.

Volgnummer

Het volgnummer is een 32-bits geheel getal dat niet is ondertekend in het gegevenskanaalbericht om de volgorde van berichten in een kanaal aan te geven. Het is belangrijk om te weten dat dit nummer wordt gegenereerd vanuit het perspectief van de afzender. Daarom kan een ontvanger een hiaat in de reeksnummers opmerken als de afzender de geadresseerden wijzigt tijdens het verzenden van berichten.

Denk bijvoorbeeld aan een scenario waarin een afzender drie berichten verzendt. In eerste instantie zijn de geadresseerden Deelnemer A en Deelnemer B. Na het eerste bericht wijzigt de afzender de ontvanger in Deelnemer B en voor het derde bericht wordt de ontvanger overgeschakeld naar deelnemer A. In dit geval ontvangt deelnemer A twee berichten met volgnummers 1 en 3. Dit betekent echter niet dat een bericht verloren gaat, maar alleen de wijziging in de geadresseerden door de afzender weerspiegelt.

Beperkingen

Berichtgrootte

De maximale toegestane grootte voor één bericht is 32 kB. Als u gegevens wilt verzenden die groter zijn dan de limiet, moet u de gegevens in meerdere berichten verdelen.

Lijst met deelnemers

Het maximum aantal deelnemers in een lijst is beperkt tot 64. Als u meer deelnemers wilt opgeven, moet u de lijst met deelnemers zelf beheren. Als u bijvoorbeeld een bericht wilt verzenden naar 50 deelnemers, kunt u twee verschillende kanalen maken, elk met 25 deelnemers in hun adressenlijsten. Bij het berekenen van de limiet worden twee eindpunten met dezelfde deelnemer-id geteld als afzonderlijke entiteiten. Als alternatief kunt u kiezen voor het uitzenden van berichten. Bepaalde beperkingen gelden echter bij het uitzenden van berichten.

Snelheidsbeperking

De aanroepende SDK heeft momenteel snelheidsbeperking geïmplementeerd, waardoor gebruikers geen gegevens met een hogere snelheid kunnen verzenden, zelfs als hun netwerk dit toestaat. De huidige bandbreedtesnelheidslimieten voor het gegevenskanaal zijn:

  • Betrouwbaar kanaal (duurzaam): 64 kbps
  • Onbetrouwbaar kanaal (Lossy): 512 kbps
  • Onbetrouwbaar kanaal met hoge prioriteit: 200 kbps

Bij het uitzenden van berichten is de limiet voor de verzendbitsnelheid echter dynamisch en is afhankelijk van de ontvangstbitsnelheid. In de huidige implementatie wordt de limiet voor de verzendbitsnelheid berekend als de maximale verzendbitrate min 80% van de ontvangstbitrate.

Daarnaast wordt ook een beperking voor pakketfrequentie afgedwongen bij het verzenden van broadcastberichten. De huidige limiet wordt ingesteld op 80 pakketten per seconde, waarbij elke 1200 bytes in een bericht wordt geteld als één pakket. Deze maatregelen zijn ingesteld om overstromingen te voorkomen wanneer een aanzienlijk aantal deelnemers aan een groepsgesprek berichten uitzendt.

Volgende stappen

Raadpleeg voor meer informatie de volgende artikelen: