Pode um TCP / IP ser eficientemente multicast entre clientes sem UDP

2

Eu tenho um aplicativo de alta largura de banda em que um servidor deve produzir dados a uma taxa de ~ 300Mb / s em uma rede gigabit. Existe uma maneira diferente de UDP para multicast para 1 a 10 clientes através de um mecanismo confiável de transporte?

Esta aplicação é muito parecida com streaming de vídeo, na medida em que a continuidade do fluxo é mais importante do que a confiabilidade. O aplicativo atual é um pouco mais lento e usa o UDP combinado com sua própria verificação de erros, na qual um cliente sabe descartar o bloco de dados.

Há alguma opção de hardware para obter um fluxo confiável de TCP / IP para vários clientes?

Existe algum protocolo que possa encapsular um fluxo de dados e oferecer suporte à correção antecipada de erros? Seria bom se o servidor / clientes ainda pudessem tratar isso como um socket normal.

Basta pensar que deve haver uma maneira melhor do que implantar sua própria solução de difusão seletiva UDP.

Observe que o servidor e os clientes podem estar na mesma sub-rede do meu aplicativo específico. Embora eu esteja interessado em todas as respostas / opções.

Obrigado.

    
por JeffV 17.02.2010 / 02:34

2 respostas

5

Multicast , por definição, usado UDP . Se o seu stream é realmente como um vídeo, você não quer tentar reenviar pacotes perdidos - isso apenas interromperia o fluxo de vídeo.

Se, no entanto, é importante que todos os pacotes cheguem lá, então você precisa de algum tipo de mensagem que possa rastrear os dados perdidos e sair da banda para reenviar todos os pacotes perdidos. Alternativamente, Multicast Geral Pragmático pode ser o que você está procurando - embora este ainda seja um protocolo experimental.

    
por 17.02.2010 / 03:21
2

Verifique se os seus comutadores suportam o IGMP . Caso contrário, a maioria dos switches falha na transmissão e 300Mb / s de tráfego de broadcast podem causar muitos problemas em sua rede.

Você também pode querer ler isso em Snooping do IGMP .

    
por 17.02.2010 / 02:52

Tags