Laufende Grafik-Display auf mehreren Systemen, synched halten

Question

Ich habe eine Reihe von Systemen auf einem LAN eine synchronisierte Anzeigeroutine ausgeführt wird. Zum Beispiel, denken Sie an einer revue. Das Programm lief sie ist fest. Ich habe jedes „Client“ die gesamte Routine herunterladen und dann Kontakt mit dem zentralen „Server“ an festen Punkten in der Routine für die Synchronisation. Die Routine selbst ist banal mit vielleicht 20 möglichen Anweisungen.

Jeder Client läuft die gleiche Routine, aber sie können völlig verschiedene Dinge zu jeder Zeit tun. Ein Teil der Chorleitung kann gelassen werden Tritte, einen anderen Teil rechts treten, aber alle in der Zeit miteinander. Kunden können jederzeit einsteigen und aussteigen, aber sie sind alle ein Teil zugewiesen. Wenn niemand da ist, das Teil zu laufen, es funktioniert einfach nicht laufen.

Das ist alles codiert in C # .Net.

Die Client-Anzeige ist ein Windows Forms-Anwendung. Der Server akzeptiert TCP-Verbindungen und anschließend auf Dienste sie reihum, eine Hauptuhr zu halten, was los ist. Die Clients senden ein Signal, das sagt: „Ich Sync-Punkt 32 erreicht haben“ (oder 19 oder 5, oder was auch immer) und wartet auf den Server zu bestätigen, und bewegt sich dann auf. Oder der Server kann sagen: „Nein, müssen Sie bei Sync-Punkt 15 beginnen“.

Das alles funktioniert super. Es gibt einen Moll wenig Verzögerung zwischen dem ersten und den letzten Kunden zu treffen ein Sync-Punkt, aber es ist kaum spürbar. Ran für Monate.

Dann wird die Spezifikation geändert.

Nun müssen die Kunden nahezu in Echtzeit Anweisungen vom Server reagieren - es ist nicht mehr ein voreingestellter Tanzprogramm. Der Server wird Anweisungen aussenden, und das Tanzprogramm wird im laufenden Betrieb aus. Ich bekomme den Job Spaß neu zu gestalten, das Protokoll, den Serviceschleife und die Programmierbefehle.

Mein Toolkit enthält alles in einer Standard-Net 3.5 Toolbox. Die Installation neuer Software kann ein Schmerz in den Arsch, da so viele Systeme (Clients) mit einbezogen werden.

Ich suche nach Anregungen zu halten den synchronisierten Clients (eine Art System der Rast? UDP? Broadcast-?), Den Vertrieb des „Tanzprogrammes“, alles, was dies leichter als eine herkömmliche Client / Server TCP Anordnung machen könnte.

Beachten Sie, dass es Zeit / Geschwindigkeitsbegrenzungen als auch los. Ich kann das Tanzprogramm in einer Netzwerk-Datenbank gestellt, aber ich hätte Anweisungen auf hart in ziemlich schnell, und es würde eine Menge Leser ein ziemlich dickes Protokoll verwenden (DBI, SqlClient, etc ..) ein kleines Stück zu bekommen von Text. Das scheint zu komplex. Und I noch etwas brauchen, um sie zu halten alle synchron angezeigt wird.

Verbesserungsvorschläge? Meinungen? Wildesel Spekulation? Code-Beispiele?

PS:. Antworten nicht als „richtigen“ markiert bekommen können (da dies keine „richtige“ Antwort ist), aber 1 Stimme für gute Vorschläge sicher

Answer 1

habe ich etwas ähnliches (eine ganze Weile zurück) mit einer Bank von 4 zeigt die Synchronisierung, die jeweils von einem einzigen System laufen, Nachrichten von einem zentralen Server zu empfangen.

Die Architektur, die wir schließlich nach einer angemessenen Menge der Prüfung ließ sich auf beteiligt einer „Master“ Maschine mit. In Ihrem Fall sein würde einen Ihrer 20 Kunden mit, der als Master fungiert, und hat es mit dem Server über TCP verbinden.

Der Server dann würde die gesamte Reihe von Befehlen für die Serie bis hin zu, dass eine Maschine senden.

Diese Maschine dann UDP verwendet, um jede der anderen Maschinen in Echtzeit Anweisungen zu übertragen (die 19 anderen Clients seiner LAN), um ihre Anzeigen zu dem Laufenden halten. Wir verwenden UDP für ein paar Gründe hier - es gab geringeren Overhead beteiligt, die nach unten die gesamten Ressourcennutzung halten half. Auch, weil Sie in Echtzeit aktualisieren, wenn ein oder zwei „Frames“ out of sync war, war es nie noticable, zumindest nicht spürbar genug für unsere Zwecke (eine menschliche Sitzung hat und mit dem System interagieren).

Der entscheidende Punkt, um dies reibungslos funktioniert, allerdings bedeutet eine intelligente Kommunikation, die zwischen dem Hauptserver und der „Master“ Maschine - Sie wollen die Bandbreite so gering wie möglich zu halten. In einem Fall wie der Ihren, würde ich wahrscheinlich mit einem einzigen binären Blob kommen, der den aktuellen Befehlssatz für die 20 Maschinen hatten, in seiner kleinsten Form. (Vielleicht so etwas wie 20 Bytes oder 40 Bytes, wenn Sie es brauchen, etc). Die „Master“ Maschine würde dann Sorge darüber hinaus zu den anderen 19 Maschinen und selbst übersetzen.

Es gibt einige nette Dinge über diese - der Server viel leichter zu einer Maschine hat im Cluster übertragen, anstatt jede Maschine im Cluster. Dies wollen wir zum Beispiel haben einen einzigen, zentralen Server „Laufwerk“ mehrere Cluster effizient, ohne überall lächerlich Hardwareanforderungen zu haben. Es hält auch der Client-Code sehr, sehr einfach. Es hat nur für ein UDP-Datagramm zu hören und tun, was es sagt -. In Ihrem Fall, es klingt wie es einen von 20 Befehlen haben würde, so dass der Kunde wird sehr, sehr einfach

Der "Master" Server ist die heikelste. In unserer Implementierung, wir hatten eigentlich den gleichen Client-Code auf mich als die anderen 19 (als separate Vorarb) und eine „Übersetzung“ Prozess, der die blob nahm, brachen es in 20 Stücke, und übermittelten sie. Es war ziemlich einfach zu schreiben, und funktionierte sehr gut.