Pergunta

Estou trabalhando em uma solução .net que funciona completamente dentro de uma única rede.Quando os usuários fazem uma alteração no sistema, quero lançar um anúncio e fazer com que todos ouçam e ajam de acordo.Existe uma maneira de podermos transmitir mensagens como esta (como o UDP permite) enquanto mantemos a entrega garantida (como o TCP)?

Isso ocorre em uma rede pequena (30 clientes), se isso fizer diferença.

Foi útil?

Solução

Quase todos os jogos precisam das propriedades de reação rápida (e, em menor grau, das propriedades sem conexão) do UDP e da confiabilidade do TCP.O que eles fazem é construir seu próprio protocolo confiável sobre UDP.Isso lhes dá a capacidade de simplesmente distribuir pacotes para qualquer lugar e, opcionalmente, torná-los confiáveis ​​também.

O sistema de pacotes confiável é geralmente um sistema simples de repetição até reconhecimento, mais simples que o TCP, mas existem protocolos que vão muito além do que o TCP pode oferecer.

Sua situação parece muito simples.Você provavelmente será capaz de criar a solução mais limpa sozinho - basta fazer com que cada cliente envie de volta uma resposta "Eu ouvi você" e faça com que o servidor continue tentando até conseguir (ou desistir).

Se você quiser algo mais, a maioria das bibliotecas de protocolos personalizados estão em C++, então não tenho certeza de quanto elas serão úteis para você.No entanto, meu conhecimento aqui tem alguns anos - talvez alguns protocolos já tenham sido portados.Hum...RakNet e enet são duas bibliotecas C/C++ que vêm à mente.

Outras dicas

Dê uma olhada sctp que possui uma combinação de recursos tcp e udp.Há uma janela implementação disponível.

Você poderia usar Espalhar para fazer comunicação em grupo.

@epatel - concordo com a sugestão do SCTP (votei, mas ainda não posso comentar, então coisas adicionais aqui).

SCTP tem muitos recursos e flexibilidade excelentes.Você pode subdividir sua conexão em vários fluxos e escolher a confiabilidade de cada um e se será ordenado ou não.Alternativamente, com o Parcialmente Confiabilidade extensão, você pode controlar a confiabilidade por mensagem.

Transmitir não é o que você deseja.Como pode haver e provavelmente haverá dispositivos conectados a esta rede que não se importam com sua mensagem, você deve usar o Multicast.Ao contrário das mensagens de difusão, que devem ser enviadas e processadas por todos os clientes da rede, as mensagens Multicast são entregues apenas aos clientes interessados ​​(ou seja, aqueles que têm alguma intenção de receber este tipo específico de mensagem e agir de acordo com ela).

Se posteriormente você ampliar esse sistema para que ele precise ser roteado em uma rede grande, o multicast poderá ser dimensionado para isso, enquanto o broadcast não, portanto, você obterá um benefício de escalabilidade que poderá apreciar mais tarde.Enquanto isso, você elimina sobrecarga desnecessária em switches e outros dispositivos que não precisam ver essas mensagens de “algo mudou”.

Você pode querer investigar RFC 3208 "Especificação do protocolo de transporte confiável PGM" .

Aqui está o resumo:

Pragmatic General Multicast (PGM) é um transporte multicast confiável
Protocolo para aplicações que requerem ordenado ou não ordenado,
Entrega de dados multicast sem duplicata, de várias fontes a
múltiplos receptores.Garantias PGM que um receptor no grupo ou recebe todos os pacotes de dados de transmissões e reparos, ou é capaz de detectar dados irrecuperáveis perda de pacotes.PGM é especificamente Concebido como uma solução viável para Aplicativos Multicast com Basic requisitos de confiabilidade.Sua central O objetivo do design é a simplicidade de operação com o devido respeito escalabilidade e eficiência de rede.

Você poderia usar um Message Broker, como ActiveMQ.
Publique suas mensagens em um tópico e faça com que os clientes registrem assinaturas duráveis ​​no tópico, para que não percam nenhuma mensagem mesmo que não estejam online.

Apache ActiveMQ é um agente de mensagens escrito em Java juntamente com um Cliente JMS.No entanto, o Apache ActiveMQ é projetado para se comunicar sobre um número de protocolos como Stomp e OpenWire juntamente com o suporte de um número de idiomas específicos diferentes Clientes.

O suporte à plataforma do cliente inclui c# e .net

Você poderia implementar seu próprio comportamento semelhante ao TCP na camada de aplicativo.

Por exemplo, você enviaria a transmissão UDP, mas esperaria uma resposta de cada host.Se você não obteve uma resposta em X segundos, envie outra e assim por diante até atingir algum tipo de limite.Se o limite for atingido (ou seja,o host não respondeu) e relate um erro.

Para fazer isso, você precisaria de uma lista predefinida de hosts dos quais esperar as respostas.

Crie um servidor TCP.Faça com que cada cliente se conecte.No seu protocolo TCP com os clientes, crie cada pacote com um prefixo de 2 bytes do tamanho total da mensagem seguinte.

Os clientes então ligam read(max_size=2) no soquete para determinar o tamanho da próxima mensagem e, em seguida, read(max_size=s) para coletar a mensagem.

Você recebe mensagens confiáveis, ordenadas e simples.Você não precisa de uma estrutura de mensagens para este.

Você definitivamente quero dar uma olhada Multicast geral pragmático:

Embora o TCP use ACKs para reconhecer grupos de pacotes enviados (algo que seria antieconômico em multicast), o PGM utiliza o conceito de Reconhecimentos Negativos (NAKs).

Para mais Mergulho G, o termo que você está procurando é multicast confiável.Dê uma olhada também TCP multicaminho.

O que você pode fazer é que após a transmissão tenha o clientes iniciar as conexões tcp.Caso contrário, basta manter uma lista de todos os clientes e iniciar você mesmo as conexões com cada cliente.

Acho que existem três opções, em termos gerais:

  1. Em vez de transmitir UDP, você pode criar uma entidade (um thread, processo, servidor, serviço ou qualquer coisa que exista em sua solução) que mantenha uma lista de assinantes e envie mensagens UDP unicast para eles.
  2. Use multicast UDP, mas você terá que escrever algum tipo de mecanismo que cuide da entrega confiável para você (ou seja, novas tentativas, tempos limite, etc.).Isso também significa que você precisa obter uma resposta de seus clientes.
  3. Se você não tem medo de protocolos de transporte experimentais, você pode procurar aqui para sugestões.,

Você deve dar uma olhada na especificação Norm (NACK-Oriented Reliable Multicast).Você pode encontrar informações sobre Norma aqui.

O protocolo NORM destina-se a: fornecer transporte confiável de ponta a ponta de objetos de dados em massa ou fluxos sobre roteamento IP multicast genérico e serviços de encaminhamento.A NORM utiliza um reconhecimento seletivo e negativo Mecanismo (NACK) de transporte confiabilidade e oferece adicionais Mecanismos de protocolo a serem conduzidos sessões multicast confiáveis com coordenação "a priori" limitada entre Remetentes e destinatários

É um tanto muito conhecido no mundo militar.

Especificações da norma.

Fonte da norma

Por que construir algo do zero se você pode usar a biblioteca?Especialmente para um projeto tão pequeno?

Tente usar Emcaster que usa mensagens multicast confiáveis ​​- PGM, é escrito em .NET e com código-fonte completo.Você obterá um ótimo mecanismo de pub/sub com filtragem de tópicos prontamente disponível.Ou você pode aprender com o código como fazer isso e basear sua própria extensão nele.

Acho que a característica mais irritante do TCP nesses cenários é a capacidade/forma de classificar os pacotes recebidos em sua ordem original - o conceito de fluxo.Você não pode ler um byte até o byte anterior à sua chegada.

Se você consegue viver sem ele, você tem a chance de ter seu protocolo, rápido e confiável, mas não para pedido de pacotes!É simplesmente impossível gerenciar os dois, porque você não pode ordenar seus bytes até receber outra cópia de um pacote perdido, essa é a principal desvantagem.

faça um multicast RDP.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top