Exécution de l'affichage graphique sur plusieurs systèmes, en gardant la synchronisation

Question

J'ai une série de systèmes sur un réseau local exécutant une routine d'affichage synchronisée. Par exemple, pensez à une ligne de chorus. Le programme qu'ils ont exécuté est corrigé. J'ai chacun "client" téléchargez la routine entière, puis contactez le "serveur" central. à des points fixes dans la routine pour la synchronisation. La routine elle-même est banale, avec peut-être 20 instructions possibles.

Chaque client exécute la même routine, mais il peut faire des choses complètement différentes à la fois. Une partie de la ligne de refrain peut être un coup de pied à gauche, une autre partie à droite, mais tout à la fois. Les clients peuvent rejoindre et abandonner à tout moment, mais ils se voient tous attribuer une partie. Si personne n’est là pour exécuter la pièce, elle ne sera tout simplement pas exécutée.

Tout cela est codé en C # .Net.

L’affichage du client est une application Windows Forms. Le serveur accepte les connexions TCP, puis les entretient tour à tour, en gardant une horloge maîtresse de ce qui se passe. Les clients envoient un signal indiquant "J'ai atteint le point de synchronisation 32". (ou 19, ou 5, ou autre) et attend que le serveur accuse réception, puis passe à autre chose. Ou le serveur peut dire "Non, vous devez commencer au point de synchronisation 15".

Tout cela fonctionne très bien. Un délai mineur a été observé entre le premier et le dernier client à atteindre un point de synchronisation, mais il est à peine perceptible. A couru pendant des mois.

La spécification a ensuite été modifiée.

Les clients doivent maintenant répondre aux instructions du serveur en temps quasi réel. Ce n'est plus un programme de danse prédéfini. Le serveur va envoyer des instructions et le programme de danse est créé à la volée. Je m'amuse à repenser le protocole, les boucles de maintenance et les instructions de programmation.

Ma boîte à outils comprend tout ce qui se trouve dans une boîte à outils .Net 3.5 standard. L’installation de nouveaux logiciels est un véritable casse-tête, car de nombreux systèmes (clients) peuvent être impliqués.

Je recherche des suggestions sur la synchronisation des clients (une sorte de système de verrouillage? UDP? Diffusion?), la distribution du "programme de danse", tout ce qui pourrait rendre cela plus facile qu'un arrangement client / serveur TCP traditionnel .

N'oubliez pas qu'il existe également des limitations de temps / vitesse. Je pourrais mettre le programme de danse dans une base de données réseau, mais je devrais insérer des instructions assez rapidement et beaucoup de lecteurs utiliseraient un protocole assez volumineux (DBI, SqlClient, etc.) pour en avoir un petit peu du texte. Cela semble trop complexe. Et j’ai toujours besoin de quelque chose pour les maintenir tous synchronisés.

Des suggestions? Des avis? Spéculation sauvage? Des exemples de code?

PS: les réponses peuvent ne pas être marquées comme "correct". (puisque ce n'est pas une réponse "correcte"), mais +1 pour de bonnes suggestions, bien sûr.

Answer 1

J'ai fait quelque chose de similaire (il y a longtemps) en synchronisant une banque de 4 écrans, chacun géré par un seul système et recevant des messages d'un serveur central.

L’architecture que nous avons finalement adoptée après de nombreux tests impliquait l’avoir un "maître". machine. Dans votre cas, il s’agirait de l’un des 20 clients qui joue le rôle de maître et de le connecter au serveur via TCP.

Le serveur enverrait alors toute la série de commandes de la série à cette machine.

Cette machine a ensuite utilisé UDP pour diffuser des instructions en temps réel à chacune des autres machines (les 19 autres clients sur son réseau local) afin de maintenir leurs affichages à jour. Nous avons utilisé le protocole UDP pour plusieurs raisons: les frais généraux impliqués étaient moins importants, ce qui a permis de limiter l'utilisation totale des ressources. De plus, comme vous mettez à jour en temps réel, si un ou deux "cadres" n'était pas synchronisé, ce n'était jamais perceptible, du moins pas assez pour nos besoins (avoir une personne assise et interagir avec le système).

Cependant, le point clé de ce bon fonctionnement réside dans la mise en place de moyens de communication intelligents entre le serveur principal et le "maître". machine - vous voulez garder la bande passante aussi basse que possible. Dans un cas comme le vôtre, je proposerais probablement un seul blob binaire contenant les instructions actuelles pour les 20 machines, dans sa forme la plus petite. (Peut-être quelque chose comme 20 octets, ou 40 octets si vous en avez besoin, etc.). Le " maître " La machine s’inquiéterait alors de la traduction de cette information en 19 autres machines.

Il y a quelques avantages à cela: le serveur a beaucoup plus de facilité à transmettre à une machine du cluster plutôt qu'à toutes les machines du cluster. Cela nous permet, par exemple, d’avoir un seul et unique serveur centralisé. plusieurs clusters efficacement, sans exigences matérielles ridicules, où que vous soyez. Cela maintient également le code client très, très simple. Il vous suffit d'écouter un datagramme UDP et de faire ce qu'il dit. Dans votre cas, cela ressemble à une des 20 commandes. Le client devient donc très, très simple.

Le " maître " le serveur est le plus délicat. Dans notre implémentation, nous avions en fait le même code client que les 19 autres (en tant que processus séparé) et un "traduction". processus qui a pris la goutte, l'a cassée en 20 morceaux et les a transmis. C'était assez simple à écrire et cela a très bien fonctionné.