Dela via

Datakanal

  • Artikel

Kommentar

Det här dokumentet går in i funktionen Data Channel som finns i Azure Communication Services Calling SDK. Även om datakanalen i det här sammanhanget har vissa likheter med datakanalen i WebRTC, är det viktigt att känna igen subtila skillnader i deras specifika egenskaper. I det här dokumentet använder vi termerna Data Channel API eller API för att ange Data Channel-API:et i SDK:n. När vi refererar till Data Channel-API:et i WebRTC använder vi uttryckligen termen WebRTC Data Channel API för tydlighet och precision.

Data Channel-API:et möjliggör realtidsmeddelanden under ljud- och videosamtal. Med det här API:et kan du nu enkelt integrera funktioner för datautbyte i programmen, vilket ger användarna en smidig kommunikationsupplevelse. Viktiga funktioner omfattar bland annat:

  • Realtidsmeddelanden: Med Data Channel-API:et kan användarna omedelbart skicka och ta emot meddelanden under ett pågående ljud- eller videosamtal, vilket främjar smidig och effektiv kommunikation. I gruppsamtalsscenarier kan meddelanden skickas till en enskild deltagare, en specifik uppsättning deltagare eller alla deltagare i samtalet. Den här flexibiliteten förbättrar kommunikationen och samarbetet mellan användare under gruppinteraktioner.
  • Enkelriktad kommunikation: Till skillnad från dubbelriktad kommunikation är Data Channel-API:et utformat för enkelriktad kommunikation. Den använder distinkta objekt för att skicka och ta emot meddelanden: DataChannelSender-objektet för att skicka och DataChannelReceiver-objektet för mottagning. Den här separationen förenklar meddelandehanteringen i gruppanrop, vilket leder till en mer effektiviserad användarupplevelse.
  • Stöd för binära data: API:et stöder sändning och mottagning av binära data, vilket tillåter utbyte av olika datatyper, till exempel text, bilder och filer. Textmeddelandena måste serialiseras till en bytebuffert innan de kan överföras.
  • Avsändaralternativ: Api:et för datakanalen innehåller tre konfigurerbara alternativ när du skapar ett avsändarobjekt, inklusive tillförlitlighet, prioritet och bithastighet. Med de här alternativen kan du konfigurera en kanal för att uppfylla specifika behov för olika användningsfall.
  • Säkerhet: Alla meddelanden som utbyts mellan en klient och den andra slutpunkten krypteras, vilket säkerställer sekretess och säkerhet för användarnas data.

Vanliga användningsfall

Datakanalen kan användas i många olika scenarier. Två vanliga exempel på användningsfall är:

Meddelanden mellan deltagare i ett samtal

Api:et för Data Channel möjliggör överföring av binärtypsmeddelanden mellan samtalsdeltagare. Med lämplig serialisering i programmet kan den leverera olika meddelandetyper för olika syften. Det finns också andra bibliotek eller tjänster som tillhandahåller meddelandefunktionerna. Var och en av dem har sina fördelar och nackdelar. Du bör välja den lämpliga för ditt användningsscenario. Till exempel erbjuder Data Channel-API:et fördelen med kommunikation med låg svarstid och förenklar användarhanteringen eftersom det inte finns något behov av att underhålla en separat deltagarlista. Datakanalfunktionen ger dock inte meddelandebeständighet och garanterar inte att meddelandet inte går förlorat från slutpunkt till slutpunkt. Om du behöver tillståndskänsliga meddelanden eller garanterad leverans kanske du vill överväga alternativa lösningar.

Fildelning

Fildelning representerar ett annat vanligt användningsfall för Data Channel-API:et. I ett peer-to-peer-anrop fungerar Data Channel-anslutningen på peer-to-peer-basis. Den här konfigurationen erbjuder en effektiv metod för filöverföring och utnyttjar den direkta peer-to-peer-anslutningen för att öka hastigheten och minska svarstiden.

I ett gruppsamtalsscenario kan filer fortfarande delas mellan deltagarna. Det finns dock bättre sätt, till exempel Azure Storage eller Azure Files. Dessutom kan sändning av filinnehållet till alla deltagare i ett anrop uppnås genom att ange en tom deltagarlista. Det är dock viktigt att komma ihåg att det, förutom bandbreddsbegränsningar, finns ytterligare begränsningar som införs under ett gruppsamtal när sändningsmeddelanden, till exempel paketfrekvens och tillbakatryck från mottagarbithastigheten.

Nyckelbegrepp

Enkelriktad kommunikation

Api:et för datakanalen är utformat för enkelriktad kommunikation, till skillnad från dubbelriktad kommunikation i WebRTC Data Channel. Den använder separata objekt för att skicka och ta emot meddelanden, med DataChannelSender-objektet som ansvarar för att skicka meddelanden och DataChannelReceiver-objektet för att ta emot meddelanden.

Avkopplingen av avsändar- och mottagarobjekt förenklar meddelandehanteringen i gruppsamtalsscenarier, vilket ger en mer effektiv och användarvänlig upplevelse.

Kanal

Varje datakanalmeddelande är associerat med en specifik kanal som identifieras av channelId. Det är viktigt att klargöra att detta channelId inte är relaterat till id egenskapen i WebRTC-datakanalen. Det här channelId kan användas för att särskilja olika programanvändningar, till exempel att använda 1000 för kontrollmeddelanden och 1001 för bildöverföringar.

ChannelId tilldelas när ett DataChannelSender-objekt skapas och kan antingen anges av användaren eller bestämmas av SDK:t om det lämnas ospecificerat.

Det giltiga intervallet för ett channelId ligger mellan 1 och 65535. Om ett channelId 0 tillhandahålls, eller om inget channelId anges, tilldelar SDK ett tillgängligt channelId inom det giltiga intervallet.

Tillförlitlighet

När du skapar kan en kanal konfigureras som ett av de två tillförlitlighetsalternativen: lossy eller durable.

En lossy kanal innebär att ordningen på meddelanden inte garanteras och att ett meddelande kan tas bort tyst när sändningen misslyckas. Det ger vanligtvis snabbare dataöverföringshastighet.

En durable kanal innebär att SDK garanterar en förlustfri och ordnad meddelandeleverans. I de fall då ett meddelande inte kan levereras utlöser SDK ett undantag. I webb-SDK:et säkerställs kanalens hållbarhet genom en tillförlitlig SCTP-anslutning. Det innebär dock inte att meddelandet inte går förlorat från slutpunkt till slutpunkt. I samband med ett gruppanrop innebär det att meddelandeförlusten mellan avsändaren och servern förhindras. I ett peer-to-peer-anrop anger det tillförlitlig överföring mellan avsändaren och fjärrslutpunkten.

Kommentar

I den aktuella Web SDK-implementeringen sker dataöverföring via en tillförlitlig WebRTC-datakanalanslutning för både lossy kanaler och durable kanaler.

Prioritet

När du skapar kan en kanal konfigureras som ett av de två prioritetsalternativen: normal eller high.

För Webb-SDK jämförs prioritetsinställningar endast mellan kanaler på avsändarsidan. Kanaler med high prioritet har högre prioritet för överföring jämfört med normal de som har prioritet.

Bitrate

När du skapar en kanal kan du ange en önskvärd bithastighet för bandbreddsallokering.

Den här bithastighetsegenskapen ska meddela SDK:t om det förväntade bandbreddskravet för ett visst användningsfall. Även om SDK:t i allmänhet inte kan matcha den exakta bithastigheten försöker det hantera begäran.

Session

Data Channel-API:et introducerar begreppet session, som följer öppen-stäng-semantik. I SDK:t associeras sessionen med avsändaren eller mottagarobjektet.

När du skapar ett avsändarobjekt med ett nytt channelId är avsändarobjektet i öppet tillstånd. Om API:et close() anropas på avsändarobjektet stängs sessionen och kan inte längre underlätta meddelandesändning. Samtidigt meddelar avsändarobjektet alla deltagare i samtalet att sessionen är stängd.

Om ett avsändarobjekt skapas med ett redan befintligt channelId stängs det befintliga avsändarobjektet som är associerat med channelId och alla meddelanden som skickas från det nyligen skapade avsändarobjektet identifieras som en del av den nya sessionen.

Från mottagarens perspektiv dirigeras meddelanden som kommer från olika sessioner på avsändarens sida till distinkta mottagarobjekt. Om SDK:n identifierar en ny session som är associerad med ett befintligt channelId på mottagarens sida skapas ett nytt mottagarobjekt. SDK:t stänger inte det äldre mottagarobjektet. sådan stängning sker 1) när mottagarobjektet tar emot ett avslutsmeddelande från avsändaren, eller 2) om sessionen inte har tagit emot några meddelanden från avsändaren på över två minuter.

I fall där sessionen för ett mottagarobjekt stängs och det inte finns någon ny session för samma channelId på mottagarens sida, skapar SDK:n ett nytt mottagarobjekt när ett meddelande tas emot från samma session vid ett senare tillfälle. Men om det finns en ny session för samma channelId på mottagarens sida tar SDK bort alla inkommande meddelanden från föregående session.

Med tanke på att mottagarobjektet stängs om det inte tar emot meddelanden på mer än två minuter föreslår vi att programmet regelbundet skickar keep-alive-meddelanden från avsändarens sida för att behålla mottagarobjektets aktiva status.

Löpnummer

Sekvensnumret är ett 32-bitars osignerat heltal som ingår i Data Channel-meddelandet för att ange ordningen på meddelanden i en kanal. Det är viktigt att notera att det här numret genereras från avsändarens perspektiv. Därför kan en mottagare märka en lucka i sekvensnumren om avsändaren ändrar mottagarna under sändningen av meddelanden.

Tänk dig till exempel ett scenario där en avsändare skickar tre meddelanden. Inledningsvis är mottagarna deltagare A och deltagare B. Efter det första meddelandet ändrar avsändaren mottagaren till Deltagare B, och före det tredje meddelandet växlas mottagaren till deltagare A. I det här fallet får deltagare A två meddelanden med sekvensnummer 1 och 3. Detta innebär dock inte en meddelandeförlust utan återspeglar bara avsändarens ändring i mottagarna.

Begränsningar

Meddelandestorlek

Den maximala tillåtna storleken för ett enskilt meddelande är 32 KB. Om du behöver skicka data som är större än gränsen måste du dela upp data i flera meddelanden.

Deltagarlista

Det maximala antalet deltagare i en lista är begränsat till 64. Om du vill ange fler deltagare måste du hantera deltagarlistan på egen hand. Om du till exempel vill skicka ett meddelande till 50 deltagare kan du skapa två olika kanaler, var och en med 25 deltagare i deras mottagarlistor. Vid beräkning av gränsen räknas två slutpunkter med samma deltagaridentifierare som separata entiteter. Som ett alternativ kan du välja sändningsmeddelanden. Vissa begränsningar gäller dock vid sändning av meddelanden.

Frekvensbegränsning

För närvarande har den anropande SDK:n hastighetsbegränsning implementerad, vilket hindrar användare från att skicka data med högre hastighet även om deras nätverk tillåter det. De aktuella maximala bandbreddsfrekvenserna för datakanalen är:

  • Reliable channel (Durable): 64 kbps
  • Opålitlig kanal (förlust): 512 kbps
  • Otillförlitlig kanal med hög prioritet: 200 kbps

Men när du sänder meddelanden är gränsen för att skicka bithastighet dynamisk och beror på bithastigheten för mottagningen. I den aktuella implementeringen beräknas gränsen för skicka bithastighet som den maximala sändningsbithastigheten minus 80 % av bithastigheten för mottagningen.

Dessutom framtvingar vi också en begränsning av pakethastigheten när du skickar sändningsmeddelanden. Den aktuella gränsen anges till 80 paket per sekund, där varje 1200 byte i ett meddelande räknas som ett paket. Dessa åtgärder är på plats för att förhindra översvämningar när ett stort antal deltagare i ett gruppsamtal sänder meddelanden.

Nästa steg

Mer information finns i följande artiklar: