Condividi tramite

Canale dati

  • Articolo

Nota

Questo documento illustra la funzionalità Canale dati presente nel Servizi di comunicazione di Azure Calling SDK. Anche se il canale dati in questo contesto presenta una certa somiglianza con il canale dati in WebRTC, è fondamentale riconoscere piccole differenze nelle specifiche. In questo documento vengono usati termini API o API del canale dati per indicare l'API del canale dati all'interno dell'SDK. Quando si fa riferimento all'API Canale dati in WebRTC, viene usato in modo esplicito il termine API del canale dati WebRTC per maggiore chiarezza e precisione.

L'API Canale dati consente la messaggistica in tempo reale durante le chiamate audio e video. Con questa API, è ora possibile integrare facilmente le funzionalità di scambio dei dati nelle applicazioni, offrendo un'esperienza di comunicazione perfetta per gli utenti. Le funzionalità principali includono:

  • Messaggistica in tempo reale: l'API Canale dati consente agli utenti di inviare e ricevere immediatamente messaggi durante una chiamata audio o video in corso, promuovendo comunicazioni fluide ed efficienti. Negli scenari di chiamata di gruppo, i messaggi possono essere inviati a un singolo partecipante, a un set specifico di partecipanti o a tutti i partecipanti all'interno della chiamata. Questa flessibilità migliora la comunicazione e la collaborazione tra gli utenti durante le interazioni di gruppo.
  • Comunicazione unidirezionale: a differenza della comunicazione bidirezionale, l'API Canale dati è progettata per la comunicazione unidirezionale. Usa oggetti distinti per l'invio e la ricezione di messaggi: l'oggetto DataChannelSender per l'invio e l'oggetto DataChannelReceiver per la ricezione. Questa separazione semplifica la gestione dei messaggi nelle chiamate di gruppo, con un'esperienza utente più semplificata.
  • Supporto dati binari: l'API supporta l'invio e la ricezione di dati binari, consentendo lo scambio di tipi di dati diversi, ad esempio testo, immagini e file. I messaggi di testo devono essere serializzati in un buffer di byte prima che possano essere trasmessi.
  • Opzioni mittente: l'API Canale dati offre tre opzioni configurabili durante la creazione di un oggetto mittente, tra cui affidabilità, priorità e velocità in bit. Queste opzioni consentono la configurazione di un canale per soddisfare esigenze specifiche per casi d'uso diversi.
  • Sicurezza: tutti i messaggi scambiati tra un client e l'altro endpoint vengono crittografati, garantendo la privacy e la sicurezza dei dati degli utenti.

Casi d'uso comuni

Il canale dati può essere usato in molti scenari diversi. Due esempi comuni di casi d'uso sono:

Messaggistica tra i partecipanti in una chiamata

L'API Canale dati consente la trasmissione di messaggi di tipo binario tra i partecipanti alla chiamata. Con la serializzazione appropriata nell'applicazione, può recapitare vari tipi di messaggio per scopi diversi. Sono disponibili anche altre librerie o servizi che forniscono le funzionalità di messaggistica. Ognuno di loro ha i suoi vantaggi e svantaggi. È consigliabile scegliere quello adatto per lo scenario di utilizzo. Ad esempio, l'API Canale dati offre il vantaggio della comunicazione a bassa latenza e semplifica la gestione degli utenti perché non è necessario mantenere un elenco di partecipanti separato. Tuttavia, la funzionalità del canale dati non fornisce la persistenza dei messaggi e non garantisce che il messaggio non andrà perso in modo end-to-end. Se è necessaria la messaggistica con stato o il recapito garantito, è consigliabile prendere in considerazione soluzioni alternative.

Condivisione di file

La condivisione di file rappresenta un altro caso d'uso comune per l'API Canale dati. In uno scenario di chiamata peer-to-peer, la connessione al canale dati funziona su base peer-to-peer. Questa configurazione offre un metodo efficiente per il trasferimento di file, sfruttando appieno la connessione diretta peer-to-peer per migliorare la velocità e ridurre la latenza.

In uno scenario di chiamata di gruppo, i file possono comunque essere condivisi tra i partecipanti. Esistono tuttavia modi migliori, ad esempio Archiviazione di Azure o File di Azure. Inoltre, è possibile trasmettere il contenuto del file a tutti i partecipanti di una chiamata impostando un elenco di partecipanti vuoto. Tuttavia, è importante tenere presente che, oltre alle limitazioni della larghezza di banda, esistono ulteriori restrizioni imposte durante una chiamata di gruppo durante la trasmissione di messaggi, ad esempio la frequenza dei pacchetti e la pressione di back pressure dalla velocità in bit di ricezione.

Concetti chiave

Comunicazione unidirezionale

L'API Canale dati è progettata per la comunicazione unidirezionale, anziché per la comunicazione bidirezionale nel canale dati WebRTC. Usa oggetti separati per l'invio e la ricezione di messaggi, con l'oggetto DataChannelSender responsabile dell'invio di messaggi e dell'oggetto DataChannelReceiver per la ricezione di messaggi.

Il disaccoppiamento degli oggetti mittente e ricevitore semplifica la gestione dei messaggi in scenari di chiamata di gruppo, offrendo un'esperienza più semplice e intuitiva.

Channel

Ogni messaggio del canale dati è associato a un canale specifico identificato da channelId. È importante chiarire che questo channelId non è correlato alla id proprietà nel canale dati WebRTC. Questo channelId può essere utilizzato per distinguere diversi usi dell'applicazione, ad esempio l'uso di 1000 per i messaggi di controllo e 1001 per i trasferimenti di immagini.

Il channelId viene assegnato durante la creazione di un oggetto DataChannelSender e può essere specificato dall'utente o determinato dall'SDK se non specificato.

L'intervallo valido di un channelId è compreso tra 1 e 65535. Se viene specificato un channelId 0 o se non viene specificato alcun channelId, l'SDK assegna un channelId disponibile dall'intervallo valido.

Affidabilità

Al momento della creazione, è possibile configurare un canale in modo che sia una delle due opzioni di affidabilità: lossy o durable.

Un lossy canale indica che l'ordine dei messaggi non è garantito e un messaggio può essere eliminato automaticamente quando l'invio non riesce. In genere offre una velocità di trasferimento dei dati più veloce.

Un durable canale indica che l'SDK garantisce un recapito di messaggi senza perdita e ordinato. Nei casi in cui non è possibile recapitare un messaggio, l'SDK genererà un'eccezione. In Web SDK la durabilità del canale viene garantita tramite una connessione SCTP affidabile. Tuttavia, non implica che il messaggio non andrà perso in modo end-to-end. Nel contesto di una chiamata di gruppo, significa la prevenzione della perdita di messaggi tra il mittente e il server. In una chiamata peer-to-peer, indica una trasmissione affidabile tra il mittente e l'endpoint remoto.

Nota

Nell'implementazione corrente di Web SDK, la trasmissione dei dati viene eseguita tramite una connessione affidabile del canale dati WebRTC per entrambi lossy i canali e durable .

Priorità

Al momento della creazione, è possibile configurare un canale in modo che sia una delle due opzioni Priorità: normal o high.

Per Web SDK, le impostazioni di priorità vengono confrontate solo tra i canali sul lato mittente. Ai canali con priorità viene assegnata una high precedenza più alta per la trasmissione rispetto a quelli con normal priorità.

Bitrate

Quando si crea un canale, è possibile specificare una velocità in bit desiderata per l'allocazione della larghezza di banda.

Questa proprietà Bitrate consiste nel notificare all'SDK il requisito di larghezza di banda previsto per un caso d'uso specifico. Anche se l'SDK in genere non può corrispondere alla velocità in bit esatta, tenta di soddisfare la richiesta.

Sessione

L'API Canale dati introduce il concetto di sessione, conforme alla semantica di chiusura aperta. Nell'SDK la sessione è associata al mittente o all'oggetto ricevitore.

Quando si crea un oggetto mittente con un nuovo channelId, l'oggetto mittente è in stato aperto. Se l'API close() viene richiamata sull'oggetto mittente, la sessione viene chiusa e non può più facilitare l'invio di messaggi. Allo stesso tempo, l'oggetto mittente notifica a tutti i partecipanti nella chiamata che la sessione è chiusa.

Se viene creato un oggetto mittente con un channelId già esistente, l'oggetto mittente esistente associato al channelId verrà chiuso e tutti i messaggi inviati dall'oggetto mittente appena creato verranno riconosciuti come parte della nuova sessione.

Dal punto di vista del ricevitore, i messaggi provenienti da sessioni diverse sul lato del mittente vengono indirizzati a oggetti ricevitori distinti. Se l'SDK identifica una nuova sessione associata a un channelId esistente sul lato del ricevitore, crea un nuovo oggetto ricevitore. L'SDK non chiude l'oggetto ricevitore precedente; tale chiusura avviene 1) quando l'oggetto ricevitore riceve una notifica di chiusura dal mittente o 2) se la sessione non ha ricevuto messaggi dal mittente per più di due minuti.

Nei casi in cui la sessione di un oggetto ricevitore viene chiusa e non esiste alcuna nuova sessione per lo stesso channelId sul lato del ricevitore, l'SDK crea un nuovo oggetto ricevitore alla ricezione di un messaggio dalla stessa sessione in un secondo momento. Tuttavia, se esiste una nuova sessione per lo stesso channelId sul lato del ricevitore, l'SDK rimuove tutti i messaggi in arrivo dalla sessione precedente.

Considerando che l'oggetto ricevitore si chiude se non riceve messaggi per più di due minuti, è consigliabile che l'applicazione invii periodicamente messaggi keep-alive dal lato del mittente per mantenere lo stato attivo dell'oggetto ricevitore.

Sequenza numerica

Il numero di sequenza è un intero senza segno a 32 bit incluso nel messaggio Canale dati per indicare l'ordine dei messaggi all'interno di un canale. È importante notare che questo numero viene generato dal punto di vista del mittente. Di conseguenza, un ricevitore può notare un gap nei numeri di sequenza se il mittente modifica i destinatari durante l'invio di messaggi.

Si consideri, ad esempio, uno scenario in cui un mittente invia tre messaggi. Inizialmente, i destinatari sono Partecipante A e Partecipante B. Dopo il primo messaggio, il mittente cambia il destinatario in Partecipante B e prima del terzo messaggio il destinatario viene passato al partecipante A. In questo caso, il partecipante A riceverà due messaggi con numeri di sequenza 1 e 3. Tuttavia, ciò non indica una perdita di messaggi, ma riflette solo la modifica nei destinatari da parte del mittente.

Limiti

Dimensione del messaggio

La dimensione massima consentita per un singolo messaggio è di 32 KB. Se è necessario inviare dati superiori al limite, è necessario dividere i dati in più messaggi.

Elenco partecipanti

Il numero massimo di partecipanti in un elenco è limitato a 64. Se vuoi specificare più partecipanti, dovrai gestire autonomamente l'elenco dei partecipanti. Ad esempio, se si vuole inviare un messaggio a 50 partecipanti, è possibile creare due canali diversi, ognuno con 25 partecipanti nelle loro liste destinatari. Quando si calcola il limite, due endpoint con lo stesso identificatore di partecipante verranno conteggiati come entità separate. In alternativa, è possibile scegliere di trasmettere messaggi. Tuttavia, alcune restrizioni si applicano durante la trasmissione dei messaggi.

Limitazione della frequenza

Attualmente l'SDK chiamante ha implementato la limitazione della velocità, che impedisce agli utenti di inviare dati a una velocità più elevata anche se la rete lo consente. I valori massimi correnti della larghezza di banda per il canale dati sono:

  • Reliable Channel (Durable): 64 kbps
  • Canale non affidabile (Perdita): 512 kbps
  • Canale non affidabile con priorità alta: 200 kbps

Tuttavia, quando si trasmettono messaggi, il limite di velocità in bit di invio è dinamico e dipende dalla velocità in bit di ricezione. Nell'implementazione corrente, il limite di velocità in bit di invio viene calcolato come velocità in bit massima di invio meno l'80% della velocità in bit di ricezione.

Inoltre, viene applicata anche una restrizione della frequenza dei pacchetti durante l'invio di messaggi di trasmissione. Il limite corrente viene impostato su 80 pacchetti al secondo, in cui ogni 1200 byte in un messaggio viene conteggiato come un pacchetto. Queste misure sono in atto per prevenire l'inondazione quando un numero significativo di partecipanti in una chiamata di gruppo trasmette messaggi.

Passaggi successivi

Per altre informazioni, vedere gli articoli seguenti: