Compartilhar via

Canal de Dados

  • Artigo

Observação

Este documento analisa a fundo o recurso Canal de Dados presente no SDK de Chamada dos Serviços de Comunicação do Azure. Embora, nesse contexto, o Canal de Dados tenha alguma semelhança com o Canal de Dados no WebRTC, é crucial reconhecer diferenças sutis nas especificidades deles. Neste documento, usamos os termos API do Canal de Dados ou API para indicar a API do Canal de Dados dentro do SDK. Ao fazer referência à API do Canal de Dados no WebRTC, usamos explicitamente o termo API do Canal de Dados do WebRTC para maior clareza e precisão.

A API do Canal de Dados permite o envio de mensagens em tempo real durante as chamadas de áudio e vídeo. Com essa API, você já pode integrar com facilidade as funcionalidades de troca de dados aos aplicativos, oferecendo 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 de vídeo contínua, promovendo uma comunicação perfeita e eficiente. Em cenários de chamada em grupo, as mensagens podem ser enviadas a um só participante, a um conjunto específico de participantes ou a todos os participantes da 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. Ela 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, resultando em uma experiência de usuário mais simplificada.
  • Suporte a dados binários: a API dá suporte ao envio e ao recebimento de dados binários, permitindo a troca de diversos tipos de dados, como texto, imagens e arquivos. As mensagens de texto precisam ser serializadas em um buffer de bytes antes de serem transmitidas.
  • Opções de remetente: a API do Canal de Dados fornece três opções configuráveis ao criar um objeto de 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 vantagens e desvantagens. Você deve escolher a opçã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 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 pela definição de 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, ao contrário da comunicação bidirecional no Canal de Dados do WebRTC. Ela emprega objetos separados para enviar e receber mensagens, com o objeto DataChannelSender, responsável por enviar mensagens, e o objeto DataChannelReceiver para receber mensagens.

O desacoplamento de objetos de remetente e destinatário simplifica o tratamento de mensagens em cenários de chamada em grupo, oferecendo 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 essa channelId não está relacionada à propriedade id no Canal de Dados do 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.

Confiabilidade

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

Um canal lossy significa que a ordem das mensagens não é garantida e uma mensagem pode ser descartada silenciosamente em caso de falha do envio. 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 vai 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 ponta a ponta. No contexto de uma chamada de grupo, isso significa a prevenção da perda de mensagens entre o remetente e o servidor. Em uma chamada ponto a ponto, isso 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 do Canal de Dados do WebRTC confiável para os canais lossy e durable.

Prioridade

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

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

Bitrate

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

Essa propriedade Bitrate serve para notificar o SDK do requisito de largura de banda esperado 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 respeita a semântica de fechamento/abertura. No SDK, a sessão é associada ao objeto de remetente ou de destinatário.

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

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

Do ponto de vista do destinatário, as mensagens provenientes de sessões diferentes no lado do remetente são direcionadas para objetos de destinatário distintos. Se o SDK identificar uma nova sessão associada a uma channelId existente no lado do destinatário, ele criará um objeto de destinatário. O SDK não fecha o objeto de destinatário mais antigo; esse fechamento ocorre 1) quando o objeto de destinatário 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.

Nos casos em que a sessão de um objeto de destinatário é fechada e não há nenhuma nova sessão para a mesma channelId no lado do destinatário, o SDK cria um objeto de destinatário 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 destinatário, o SDK descartará todas as mensagens de entrada da sessão anterior.

Considerando que o objeto de destinatário 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 de destinatário.

Número de 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 em um canal. É importante observar que esse número é gerado da perspectiva do remetente. Consequentemente, um destinatário 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 o Participante A e o 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 mensagem individual é 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 nas listas de destinatários. Ao calcular o limite, dois pontos de extremidade com o mesmo identificador de participante serão contados como entidades separadas. Como alternativa, você pode optar por transmitir mensagens. No entanto, algumas restrições se aplicam à transmissão de 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 a sua rede permita isso. Os valores 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 (com perdas): 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 impomos 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 1.200 bytes de uma mensagem é contado como um pacote. Essas medidas entram em vigor para evitar inundações quando um número significativo de participantes em uma chamada de grupo transmite mensagens.

Próximas etapas

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