Ejecución de visualización de gráficos en múltiples sistemas, manteniéndose sincronizado

Question

Tengo una serie de sistemas en una LAN que ejecutan una rutina de visualización sincronizada. Por ejemplo, piense en una línea de coro. El programa que corrieron es fijo. Tengo cada '' cliente '' descargue la rutina completa y luego póngase en contacto con el "servidor" central en puntos fijos en la rutina para la sincronización. La rutina en sí es mundana con, quizás, 20 instrucciones posibles.

Cada cliente ejecuta la misma rutina, pero pueden estar haciendo cosas completamente diferentes en cualquier momento. Una parte de la línea del coro puede ser patear hacia la izquierda, otra parte hacia la derecha, pero todo a tiempo entre sí. Los clientes pueden unirse y abandonar en cualquier momento, pero a todos se les asigna una parte. Si no hay nadie para ejecutar la pieza, simplemente no se ejecuta.

Todo esto está codificado en C # .Net.

La pantalla del cliente es una aplicación de formularios Windows Forms. El servidor acepta conexiones TCP, y luego las atiende de manera circular, manteniendo un reloj maestro de lo que está sucediendo. Los clientes envían una señal que dice "He alcanzado el punto de sincronización 32". (o 19, o 5, o lo que sea) y espera a que el servidor lo reconozca y luego continúa. O el servidor puede decir "No, debe comenzar en el punto de sincronización 15".

Todo esto funciona muy bien. Hay un retraso menor entre el primer y el último cliente en alcanzar un punto de sincronización, pero apenas se nota. Funcionó durante meses.

Luego la especificación cambió.

Ahora los clientes deben responder a las instrucciones casi en tiempo real del servidor; ya no es un programa de baile preestablecido. El servidor va a enviar instrucciones y el programa de baile está hecho sobre la marcha. Obtengo el divertido trabajo de rediseñar el protocolo, los bucles de servicio y las instrucciones de programación.

Mi kit de herramientas incluye cualquier cosa en una caja de herramientas estándar .Net 3.5. Instalar un nuevo software es una molestia, ya que muchos sistemas (clientes) pueden estar involucrados.

Estoy buscando sugerencias para mantener sincronizados a los clientes (¿algún tipo de sistema de enclavamiento? ¿UDP? ¿Difusión?), distribución del "programa de baile", cualquier cosa que pueda hacer esto más fácil que un arreglo TCP / Cliente tradicional. .

Tenga en cuenta que también hay limitaciones de tiempo / velocidad. Podría poner el programa de baile en una base de datos de red, pero tendría que introducir las instrucciones con bastante rapidez y habría muchos lectores usando un protocolo bastante grueso (DBI, SqlClient, etc.) para obtener un poco de texto Eso parece demasiado complejo. Y todavía necesito algo para mantenerlos a todos sincronizados.

Sugerencias? Opiniones? ¿Especulación salvaje? Ejemplos de código?

PD: es posible que las respuestas no se marquen como "correcto" (ya que esta no es una respuesta "correcta"), pero +1 vota por buenas sugerencias con seguridad.

Answer 1

Hice algo similar (hace un tiempo) sincronizando un banco de 4 pantallas, cada una ejecutada por un solo sistema, recibiendo mensajes de un servidor central.

La arquitectura en la que finalmente nos decidimos después de una buena cantidad de pruebas implicó tener un '' maestro '' máquina. En su caso, esto sería tener uno de sus 20 clientes que actúe como maestro y que se conecte al servidor a través de TCP.

El servidor luego enviaría toda la serie de comandos para la serie a través de esa máquina.

Esa máquina luego usó UDP para transmitir instrucciones en tiempo real a cada una de las otras máquinas (los otros 19 clientes en su LAN) para mantener sus pantallas actualizadas. Aquí utilizamos UDP por un par de razones: hubo una sobrecarga menor, lo que ayudó a mantener bajo el uso total de recursos. Además, dado que está actualizando en tiempo real, si uno o dos "fotogramas" no estaba sincronizado, nunca fue notable, al menos no lo suficientemente notable para nuestros propósitos (tener un humano sentado e interactuando con el sistema).

Sin embargo, el punto clave para que esto funcione sin problemas es tener un medio de comunicación inteligente entre el servidor principal y el "maestro". máquina: desea mantener el ancho de banda lo más bajo posible. En un caso como el tuyo, probablemente se me ocurra un blob binario único que tenga la instrucción actual establecida para las 20 máquinas, en su forma más pequeña. (Tal vez algo así como 20 bytes, o 40 bytes si lo necesita, etc.). El "maestro" entonces la máquina se preocuparía por traducir esto a las otras 19 máquinas y a sí mismo.

Hay algunas cosas buenas acerca de esto: al servidor le resulta mucho más fácil transmitir a una máquina en el clúster en lugar de a todas las máquinas en el clúster. Esto nos permite, por ejemplo, tener un único servidor centralizado '' unidad '' múltiples clústeres de manera eficiente, sin tener requisitos de hardware ridículos en ningún lado. También mantiene el código del cliente muy, muy simple. Solo tiene que escuchar un datagrama UDP y hacer lo que sea que diga: en su caso, parece que tendría uno de los 20 comandos, por lo que el cliente se vuelve muy, muy simple.

El "maestro" El servidor es el más complicado. En nuestra implementación, en realidad teníamos el mismo código de cliente que los otros 19 (como un proceso separado) y una '' traducción '' proceso que tomó el blob, lo partió en 20 pedazos y los transmitió. Fue bastante simple de escribir y funcionó muy bien.