Compartilhar via

Canal de Dados

Observação

Este documento se aprofunda no recurso de Canal de Dados presente no SDK de Chamadas dos Serviços de Comunicação do Azure. Embora o Canal de Dados nesse contexto tenha alguma semelhança com o Canal de Dados no WebRTC, é crucial reconhecer diferenças sutis em suas especificidades. Ao longo deste documento, usamos os termos API de Canal de Dados ou API para denotar a API de Canal de Dados dentro do SDK. Ao fazer referência à API do Canal de Dados no WebRTC, usamos explicitamente o termo API de Canal de Dados webRTC para maior clareza e precisão.

A API do Canal de Dados habilita o sistema de mensagens em tempo real durante chamadas de áudio e vídeo. Com essa API, agora você pode integrar facilmente as funcionalidades de troca de dados aos aplicativos, fornecendo uma experiência de comunicação perfeita para os usuários. Os principais recursos incluem:

  • Mensagens em tempo real: a API do Canal de Dados permite que os usuários enviem e recebam mensagens instantaneamente durante uma chamada de áudio ou vídeo contínua, promovendo uma comunicação suave e eficiente. Em cenários de chamada em grupo, as mensagens podem ser enviadas a um único participante, a um conjunto específico de participantes ou a todos os participantes na chamada. Essa flexibilidade aprimora a comunicação e a colaboração entre os usuários durante as interações de grupo.
  • Comunicação unidirecional: ao contrário da comunicação bidirecional, a API do Canal de Dados foi projetada para comunicação unidirecional. Ele emprega objetos distintos para enviar e receber mensagens: o objeto DataChannelSender para envio e o objeto DataChannelReceiver para recebimento. Essa separação simplifica o gerenciamento de mensagens em chamadas de grupo, levando a uma experiência de usuário mais simplificada.
  • Suporte a dados binários: a API dá suporte ao envio e recebimento de dados binários, permitindo a troca de diversos tipos de dados, como texto, imagens e arquivos. As mensagens de texto devem ser serializadas em um buffer de bytes antes de serem transmitidas.
  • Opções do remetente: a API do Canal de Dados fornece três opções configuráveis ao criar um objeto remetente, incluindo Confiabilidade, Prioridade e Taxa de Bits. Essas opções permitem que a configuração de um canal atenda a necessidades específicas para diferentes casos de uso.
  • Segurança: todas as mensagens trocadas entre um cliente e o outro ponto de extremidade são criptografadas, garantindo a privacidade e a segurança dos dados dos usuários.

Casos de uso comuns

O Canal de Dados pode ser usado em muitos cenários diferentes. Dois exemplos comuns de casos de uso são:

Mensagens entre participantes em uma chamada

A API do Canal de Dados permite a transmissão de mensagens de tipo binário entre os participantes da chamada. Com a serialização apropriada no aplicativo, ela pode fornecer vários tipos de mensagem para diferentes finalidades. Há também outras bibliotecas ou serviços que fornecem as funcionalidades de mensagens. Cada um deles tem suas vantagens e desvantagens. Você deve escolher o adequado para seu cenário de uso. Por exemplo, a API do Canal de Dados oferece a vantagem da comunicação de baixa latência e simplifica o gerenciamento de usuários, pois não é necessário manter uma lista de participantes separada. No entanto, o recurso de canal de dados não fornece persistência de mensagem e não garante que a mensagem não será perdida de maneira de ponta a ponta. Se você precisar de mensagens com estado ou entrega garantida, o ideal é considerar soluções alternativas.

Compartilhamento de arquivos

O compartilhamento de arquivos representa outros casos de uso comuns para a API do Canal de Dados. Em um cenário de chamada ponto a ponto, a conexão do Canal de Dados funciona de modo ponto a ponto. Essa configuração oferece um método eficiente para transferência de arquivos, aproveitando ao máximo a conexão direta ponto a ponto para aprimorar a velocidade e reduzir a latência.

Em um cenário de chamada em grupo, os arquivos ainda podem ser compartilhados entre os participantes. No entanto, há maneiras melhores, como o Armazenamento do Azure ou os Arquivos do Azure. Além disso, a transmissão do conteúdo do arquivo para todos os participantes em uma chamada pode ser obtida definindo uma lista de participantes vazia. No entanto, é importante ter em mente que, além das limitações de largura de banda, há restrições adicionais impostas durante uma chamada em grupo ao transmitir mensagens, como taxa de pacotes e pressão de retorno da taxa de bits de recebimento.

Conceitos principais

Comunicação unidirecional

A API do Canal de Dados foi projetada para comunicação unidirecional, em oposição à comunicação bidirecional no Canal de Dados webRTC. Ele emprega objetos separados para enviar e receber mensagens, com o objeto DataChannelSender responsável por enviar mensagens e o objeto DataChannelReceiver para receber mensagens.

A desacoplamento de objetos remetente e receptor simplifica o tratamento de mensagens em cenários de chamada em grupo, fornecendo uma experiência mais simplificada e fácil de usar.

Canal

Cada mensagem do Canal de Dados está associada a um canal específico identificado por channelId. É importante esclarecer que esse channelId não está relacionado à propriedade id no Canal de Dados WebRTC. Essa channelId pode ser utilizada para diferenciar vários usos de aplicativo, como o uso de 1000 para mensagens de controle e 1001 para transferências de imagem.

A channelId é atribuída durante a criação de um objeto DataChannelSender e pode ser especificada pelo usuário ou determinada pelo SDK se não for especificada.

O intervalo válido de uma channelId está entre 1 e 65535. Se uma channelId 0 for fornecida ou se nenhuma channelId for fornecida, o SDK atribuirá uma channelId disponível dentro do intervalo válido.

Fiabilidade

Após a criação, um canal pode ser configurado para ser uma das duas opções de confiabilidade: lossy ou durable.

Um lossy canal significa que a ordem das mensagens não é garantida e uma mensagem pode ser descartada silenciosamente quando o envio falhar. Geralmente, ele oferece uma velocidade de transferência de dados mais rápida.

Um canal durable significa que o SDK garante uma entrega de mensagens ordenadas e sem perdas. Nos casos em que uma mensagem não puder ser entregue, o SDK gerará uma exceção. No SDK da Web, a durabilidade do canal é assegurada por meio de uma conexão SCTP confiável. No entanto, isso não implica que a mensagem não será perdida de maneira de ponta a ponta. No contexto de uma chamada de grupo, significa a prevenção da perda de mensagens entre o remetente e o servidor. Em uma chamada ponto a ponto, ela indica a transmissão confiável entre o remetente e o ponto de extremidade remoto.

Observação

Na implementação atual do SDK da Web, a transmissão de dados é feita por meio de uma conexão de Canal de Dados WebRTC confiável para os canais lossy e durable.

Prioridade

Após a criação, um canal pode ser configurado para ser uma das duas opções de prioridade: normal ou high.

Para o SDK da Web, as configurações de prioridade são comparadas somente entre canais no lado do remetente. Canais com high prioridade recebem precedência maior para transmissão em comparação com os com normal prioridade.

Velocidade de transmissão

Ao criar um canal, uma taxa de bits desejável pode ser especificada para alocação de largura de banda.

Esta propriedade de bitrate é para notificar o SDK sobre a necessidade de largura de banda estimada para um caso de uso específico. Embora o SDK geralmente não possa corresponder à taxa de bits exata, ele tenta acomodar a solicitação.

Sessão

A API do Canal de Dados apresenta o conceito de uma sessão, que adere à semântica de fechamento aberto. No SDK, a sessão é associada ao remetente ou ao objeto receptor.

Ao criar um objeto remetente com uma nova channelId, o objeto remetente está em estado aberto. Se a close() API for invocada no objeto remetente, a sessão ficará fechada e não poderá mais facilitar o envio de mensagens. Ao mesmo tempo, o objeto remetente notifica todos os participantes na chamada de que a sessão está fechada.

Se um objeto remetente for criado com uma channelId já existente, o objeto remetente existente associado à channelId será fechado e todas as mensagens enviadas do objeto remetente recém-criado serão reconhecidas como parte da nova sessão.

Do ponto de vista do receptor, as mensagens provenientes de sessões diferentes no lado do remetente são direcionadas para objetos receptores distintos. Se o SDK identificar uma nova sessão associada a uma channelId existente no lado do receptor, ele criará um novo objeto receptor. O SDK não fecha o objeto receptor mais antigo; esse fechamento ocorre 1) quando o objeto receptor recebe uma notificação de fechamento do remetente ou 2) se a sessão não tiver recebido nenhuma mensagem do remetente por mais de dois minutos.

Em casos em que a sessão de um objeto receptor é fechada e nenhuma nova sessão para a mesma channelId existe no lado do receptor, o SDK cria um novo objeto receptor após o recebimento de uma mensagem da mesma sessão posteriormente. No entanto, se houver uma nova sessão para a mesma channelId no lado do receptor, o SDK descartará todas as mensagens de entrada da sessão anterior.

Considerando que o objeto receptor será fechado se ele não receber mensagens por mais de dois minutos, sugerimos que o aplicativo envie periodicamente mensagens keep-alive do lado do remetente para manter o status ativo do objeto receptor.

Número da sequência

O número de sequência é um inteiro sem sinal de 32 bits incluído na mensagem do canal de dados para indicar a ordem das mensagens dentro de um canal. É importante observar que esse número é gerado da perspectiva do remetente. Consequentemente, um receptor poderá notar uma lacuna nos números de sequência se o remetente alterar os destinatários durante o envio de mensagens.

Por exemplo, considere um cenário em que um remetente envia três mensagens. Inicialmente, os destinatários são Participante A e Participante B. Após a primeira mensagem, o remetente altera o destinatário para o Participante B e, antes da terceira mensagem, o destinatário é alternado para o participante A. Nesse caso, o Participante A receberá duas mensagens com os números de sequência 1 e 3. No entanto, isso não significa uma perda de mensagem, mas reflete apenas a alteração nos destinatários pelo remetente.

Limitações

Tamanho da mensagem

O tamanho máximo permitido para uma única mensagem é de 32 KB. Se você precisar enviar dados maiores que o limite, precisará dividir os dados em várias mensagens.

Lista de participantes

O número máximo de participantes em uma lista é limitado a 64. Se você quiser especificar mais participantes, precisará gerenciar a lista de participantes por conta própria. Por exemplo, se você quiser enviar uma mensagem para 50 participantes, poderá criar dois canais diferentes, cada um com 25 participantes em suas listas de destinatários. Ao calcular o limite, duas extremidades com o mesmo identificador de participante serão consideradas entidades distintas. Como alternativa, você pode optar por transmitir mensagens. No entanto, determinadas restrições se aplicam ao transmitir mensagens.

Limitação de taxa

Atualmente, o SDK de chamada tem a limitação de taxa implementada, o que impede que os usuários enviem dados em uma velocidade mais alta, mesmo que sua rede permita isso. Os máximos atuais de taxa de largura de banda para o canal de dados são:

  • Canal confiável (durável): 64 kbps
  • Canal não confiável (Lossy): 512 kbps
  • Canal não confiável de alta prioridade: 200 kbps

No entanto, ao transmitir mensagens, o limite de taxa de bits de envio é dinâmico e depende da taxa de bits de recebimento. Na implementação atual, o limite de taxa de bits de envio é calculado como a taxa máxima de bits de envio menos 80% da taxa de bits de recebimento.

Além disso, também impõemos uma restrição de taxa de pacote ao enviar mensagens de transmissão. O limite atual é definido em 80 pacotes por segundo, em que cada 1200 bytes em uma mensagem é contado como um pacote. Essas medidas estão em vigor para evitar inundações quando um número significativo de participantes em uma chamada de grupo está transmitindo mensagens.

Próximas etapas

Para obter mais informações, consulte os seguintes artigos: