Esecuzione della visualizzazione grafica su più sistemi, mantenendo sincronizzato

Question

Ho una serie di sistemi su una LAN che esegue una routine di visualizzazione sincronizzata. Ad esempio, pensa a una linea di chorus. Il programma che hanno eseguito è stato risolto. Ho ciascuno " client " scarica l'intera routine, quindi contatta il "server" centrale in punti fissi nella routine per la sincronizzazione. La routine stessa è banale con, forse, 20 possibili istruzioni.

Ogni client esegue la stessa routine, ma può fare cose completamente diverse in qualsiasi momento. Una parte della linea del chorus può essere calciata a sinistra, un'altra parte calciata a destra, ma tutte in tempo tra loro. I clienti possono aderire e abbandonare in qualsiasi momento, ma a tutti viene assegnata una parte. Se nessuno è lì per eseguire la parte, semplicemente non viene eseguita.

Questo è tutto codificato in C # .Net.

Il display client è un'applicazione Windows Form. Il server accetta le connessioni TCP, e quindi le assiste alla moda round robin, mantenendo un master clock di ciò che sta succedendo. I client inviano un segnale che dice "Ho raggiunto il punto di sincronizzazione 32" (o 19, o 5 o qualsiasi altra cosa) e attende che il server riconosca e quindi passa. Oppure il server può dire "No, devi iniziare dal punto di sincronizzazione 15".

Tutto funziona alla grande. C'è un po 'di minore ritardo tra il primo e l'ultimo client a raggiungere un punto di sincronizzazione, ma è appena percettibile. Ha funzionato per mesi.

Quindi le specifiche sono cambiate.

Ora i client devono rispondere alle istruzioni quasi in tempo reale dal server: non è più un programma di ballo preimpostato. Il server invierà le istruzioni e il programma di ballo sarà inventato al volo. Ho il lavoro divertente di riprogettare il protocollo, i cicli di manutenzione e le istruzioni di programmazione.

Il mio toolkit include qualsiasi cosa in un toolbox standard .Net 3.5. L'installazione di nuovo software è una seccatura, poiché possono essere coinvolti così tanti sistemi (client).

Sto cercando suggerimenti su come mantenere i client sincronizzati (una sorta di sistema di latching? UDP? Broadcast?), distribuzione del "programma dance", tutto ciò che potrebbe renderlo più semplice di un tradizionale accordo TCP Client / Server .

Tieni presente che ci sono anche limiti di tempo / velocità. Potrei mettere il programma dance in un database di rete, ma dovrei inserire le istruzioni abbastanza rapidamente e ci sarebbero molti lettori che usano un protocollo piuttosto denso (DBI, SqlClient, ecc.) Per ottenere un po ' di testo. Sembra troppo complesso. E ancora ho bisogno di qualcosa per mantenerli tutti sincronizzati.

Suggerimenti? Opinioni? Speculazione selvaggia? Esempi di codice?

PS: le risposte potrebbero non essere contrassegnate come " corrette " (poiché questa non è una risposta "corretta"), ma +1 voti per buoni suggerimenti di sicuro.

Answer 1

Ho fatto qualcosa di simile (un po 'di tempo fa) con la sincronizzazione di un banco di 4 schermi, ciascuno gestito da un singolo sistema, che riceveva messaggi da un server centrale.

L'architettura su cui ci siamo finalmente basati dopo una buona dose di test ha comportato un "master" macchina. Nel tuo caso, si tratterebbe di avere uno dei tuoi 20 client che funge da master e di collegarlo al server tramite TCP.

Il server invierebbe quindi l'intera serie di comandi per la serie a quell'unica macchina.

Quella macchina ha quindi usato UDP per trasmettere istruzioni in tempo reale a ciascuna delle altre macchine (gli altri 19 client sulla sua LAN) per mantenere aggiornati i loro schermi. Abbiamo usato UDP per un paio di ragioni qui - c'era un sovraccarico inferiore, che ha contribuito a contenere l'utilizzo totale delle risorse. Inoltre, poiché stai aggiornando in tempo reale, se uno o due "frame" non era sincronizzato, non era mai evidente, almeno non abbastanza evidente per i nostri scopi (avere una posizione umana e interagire con il sistema).

Il punto chiave per far funzionare senza problemi, però, è avere un mezzo di comunicazione intelligente tra il server principale e il "master" macchina - vuoi mantenere la larghezza di banda più bassa possibile. In un caso come il tuo, probabilmente avrei escogitato un unico blob binario che aveva impostato le istruzioni correnti per le 20 macchine, nella sua forma più piccola. (Forse qualcosa come 20 byte o 40 byte se ne hai bisogno, ecc.). Il "master" machine si preoccuperebbe quindi di tradurlo nelle altre 19 macchine e in se stesso.

Ci sono alcune cose carine in questo: il server ha un tempo molto più facile di trasmissione a una macchina nel cluster invece di ogni macchina nel cluster. Questo ci consente, ad esempio, di avere un singolo server centralizzato "drive". più cluster in modo efficiente, senza requisiti hardware ridicoli ovunque. Mantiene anche il codice client molto, molto semplice. Deve solo ascoltare un datagramma UDP e fare tutto ciò che dice - nel tuo caso sembra che avrebbe uno dei 20 comandi, quindi il client diventa molto, molto semplice.

Il " master " il server è il più complicato. Nella nostra implementazione, avevamo effettivamente lo stesso codice client su di esso degli altri 19 (come processi separati) e uno "traduzione". processo che ha preso il blob, lo ha suddiviso in 20 pezzi e li ha trasmessi. È stato abbastanza semplice da scrivere e ha funzionato molto bene.