Correndo exibição de gráficos em vários sistemas, mantendo sincronizada

Question

Eu tenho uma série de sistemas em uma LAN executando uma rotina de exibição sincronizada. Por exemplo, pense em uma linha de coro. O programa que correu é fixo. Eu tenho cada "cliente" baixar a rotina inteira, e, em seguida, entre em contato com o "servidor" central em pontos fixos na rotina para sincronização. A rotina em si é mundano com, talvez, 20 possíveis instruções.

Cada cliente executa a mesma rotina, mas eles podem estar fazendo coisas completamente diferentes a qualquer momento um. Uma parte da linha de coro pode ser chutando à esquerda, outra parte chutando bem, mas tudo em tempo uns com os outros. Os clientes podem juntar-se e cair fora a qualquer momento, mas eles estão todos atribuídos uma parte. Se ninguém está lá para executar a parte, ele simplesmente não se partem.

Isso tudo é codificado em C # .Net.

A exibição do cliente é uma aplicação Windows Forms. O servidor aceita conexões TCP, e depois serviços lhes moda round-robin, mantendo um relógio mestre do que está acontecendo. Os clientes enviam um sinal que diz "Cheguei sync point-32" (ou 19, ou 5, ou qualquer outro) e aguarda o servidor para reconhecer e então se move. Ou o servidor pode dizer "Não, você precisa para começar a sincronização ponto-15".

Isso tudo funciona muito bem. Há um menor pouco de atraso entre a primeira ea última clientes para bater um ponto de sincronização, mas é dificilmente perceptível. Ran por meses.

Em seguida, a especificação alterada.

Agora, os clientes precisam para responder às instruções perto em tempo real do servidor - ele não é mais um programa de dança pre-set. O servidor vai ser o envio de instruções para fora e o programa de dança é feita em cima da mosca. Recebo o trabalho divertido do protocolo projetar reemergentes, bem como os loops de manutenção, e as instruções de programação.

O meu kit de ferramentas inclui qualquer coisa em um padrão Net 3.5 caixa de ferramentas. Instalação de novo software é um pé no saco, uma vez que muitos sistemas (clientes) podem estar envolvidos.

Eu estou procurando sugestões sobre como manter os clientes sincronizados (algum tipo de sistema de travamento? UDP? Transmissão?), A distribuição do "programa de dança", qualquer coisa que pode tornar isso mais fácil do que um arranjo tradicional cliente / servidor TCP.

Tenha em mente que existem limitações de tempo / velocidade acontecendo também. Eu poderia colocar o programa de dança em um banco de dados de rede, mas eu teria que empurrar instruções muito rapidamente e que haveria um monte de leitores através de um protocolo em vez de espessura (DBI, SqlClient, etc ..) para obter um pequeno pedaço de texto. Isso parece excessivamente complexa. E eu ainda precisa de algo para mantê-los todos exibindo em sincronia.

Sugestões? Opiniões? especulação-burro? exemplos de código?

PS:. As respostas podem não ser marcado como "correta" (uma vez que esta não é uma resposta "correta"), mas +1 votos para boas sugestões para certificar

Answer 1

Eu fiz algo semelhante (um bom tempo de volta) com a sincronização de um banco de 4 monitores, cada um dirigido por um sistema único e receber mensagens de um servidor central.

A arquitetura finalmente resolvido depois de uma boa quantidade de testes envolvidos ter uma máquina "mestre". No seu caso, isso seria ter um de seus 20 clientes, que atua como o mestre, e tê-lo conectar ao servidor via TCP.

O servidor, em seguida, iria enviar toda a série de comandos para a série até que a máquina um.

Essa máquina, em seguida, usado UDP com as instruções em tempo real de transmissão para cada uma das outras máquinas (os outros 19 clientes em seu LAN) para manter suas exposições até à data. Usamos UDP por dois motivos aqui - não foi menor sobrecarga envolvida, o que ajudou a manter o baixo de utilização total de recursos. Além disso, desde que você está atualizando em tempo real, se um ou dois "frames" estava fora de sincronia, nunca foi perceptível, pelo menos não perceptível o suficiente para os nossos propósitos (com um humano sentado e interagindo com o sistema).

O ponto-chave para esta funcionando sem problemas, no entanto, é ter um meio de comunicação inteligente entre o servidor principal e a máquina "mestre" - que pretende manter a largura de banda mais baixo possível. Em um caso como o seu, eu provavelmente vir acima com um único blob binário que tinha o conjunto de instruções atual para as 20 máquinas, em sua menor forma. (Talvez algo como 20 bytes, ou 40 bytes se você precisar dele, etc). O "master" máquina faria depois se preocupar com traduzir isso para as outras 19 máquinas e em si.

Há algumas coisas agradáveis ??sobre este - o servidor tem uma transmissão muito mais fácil tempo para uma máquina no cluster em vez de cada máquina no cluster. Este deixar-nos, por exemplo, ter um único servidor "Drive", centralizado vários clusters de forma eficiente, sem ter requisitos de hardware ridículas em qualquer lugar. Ele também mantém o código do cliente muito, muito simples. Ele só tem que ouvir um datagrama UDP e fazer o que ele diz - no seu caso, parece que ele teria um dos 20 comandos, para que o cliente se torna muito, muito simples

.

O servidor "mestre" é o mais complicado. Em nossa aplicação, nós realmente tinha o mesmo código de cliente sobre ele como os outros 19 (como um proces separados) e um processo de "tradução" que tomou o blob, quebrou-a em 20 pedaços, e transmitiu-los. Era bastante simples de escrever, e funcionou muito bem.