Topologia di rete suggerita per questa applicazione di trasmissione dati/comando di dimensioni ridotte?

Question

Stiamo assemblando un sistema che legge ~ 32 segnali di tensione attraverso una scheda convertitore analogico-digitale, esegue alcune elaborazioni preliminari su di essi e passa i risultati (ancora separati in 32 canali) alla rete come pacchetti UDP, dove vengono prelevati da un altro computer e variamente (a) visualizzato, (b) ulteriormente elaborato, (c) cercato i criteri per cambiare lo stato del sistema di acquisizione, o (d) una combinazione di AC. Contemporaneamente un processo GUI è in esecuzione sul computer eseguendo questi ultimi processi (il computer vis), che cambia stato sia nel computer che genera i dati sia nei processi multipli del computer vis, attraverso i messaggi di comando in pacchetti UDP.

Sono nuovo alla programmazione di rete e sto lottando per scegliere una topologia di rete. Esistono euristiche (o capitoli di libri, documenti) sulla topologia della rete per applicazioni relativamente piccole rispetto alla necessità di trasmettere dati, comandi e comandi di riconoscimento in modo flessibile?

dettagli di sistema:

• Raw acquisizione dei dati avviene su un'unica macchina Linux. La semplice elaborazione dei dati, il salvataggio su disco e il trasferimento sulla rete utilizzano circa il 25% della capacità della CPU e una piccola quantità di memoria. Meno di 0,5 Mb/sec di dati vanno alla rete. Tutto il codice per la generazione dei dati è in C++.

• Un'altra macchina Linux esegue diversi processi di visualizzazione/elaborazione/GUI. La GUI controlla sia la macchina di acquisizione che i processi sul computer vis/processing/GUI stesso. Questo codice è principalmente in C++, con un paio di piccole utility in Python.

• Scriviamo altre applicazioni che vorranno ascoltare i dati grezzi, i dati elaborati e tutti i comandi passati; quelle applicazioni vorranno anche emettere comandi - non possiamo anticipare quanti moduli di questo tipo vogliamo scrivere, ma ci aspettiamo 3 o 4 processi pesanti in termini di dati che trasformino tutti i 32 flussi di input in un singolo output; così come 3 o 4 piccole applicazioni come un "registratore di comandi". Il requisito della modularità significa che vogliamo che i vecchi generatori di dati e gli emittenti di comandi siano agnostici sul numero di ascoltatori disponibili. Vogliamo anche che i comandi siano riconosciuti dai loro destinatari.

• Le due macchine sono collegate da uno switch e i pacchetti (dati e comandi e riconoscimenti) vengono inviati in UDP.

I cinque possibilità che stiamo pensando di:

1. Flussi di dati, comandi, e riconoscimenti sono mirati in base al numero di porta. Il generatore di dati invia flussi di dati indipendenti come pacchetti UDP a numeri di porta diversi legati da processi di visualizzazione indipendenti sul computer di visualizzazione. Ogni processo associa anche una porta di ascolto per i comandi in entrata e un'altra porta per i riconoscimenti ricevuti ai comandi in uscita. Questa opzione sembra buona perché il kernel fa il lavoro di trafficare/filtrare i pacchetti; ma male perché è difficile vedere come i processi si affrontino a vicenda di fronte a moduli aggiunti non previsti; sembra anche portare a un'esplosione di porti vincolati.

2. I flussi di dati sono indirizzati ai rispettivi visualizzatori per numero di porta e ogni processo associa una porta per l'ascolto di comandi. Ma tutti gli emittenti di comandi inviano i loro comandi a un processo di inoltro di pacchetti che conosce le porte di comando di tutti i processi e inoltra ogni comando a tutti loro. Anche i ringraziamenti vengono inviati a questa porta di comando universale e inoltrati a tutti i processi.Forniamo informazioni sul bersaglio previsto di ciascun comando e ogni conferma nei pacchetti command/ack, quindi i processi stessi devono setacciare tutti i comandi/acks per trovare quelli che appartengono ad essi.

3. Il processo del pacchetto di inoltro è anche la destinazione di tutti i pacchetti di dati. Tutti i pacchetti di dati e tutti i pacchetti di comando vengono inoltrati a circa 40 processi diversi. Questo ovviamente mette molto più traffico sulla sottorete; inoltre ripulisce l'esplosione delle porte vincolate.

4. Due pacchetti-distributori possono essere eseguiti sul computer vis - uno trasmette i comandi/ack a tutte le porte. L'altro trasmette i dati solo alle porte che potrebbero desiderare i dati.

5. I nostri 32 processi di visualizzazione possono essere raggruppati in 1 processo che disegna i dati per i 32 segnali, riducendo notevolmente il traffico aggiuntivo causato dall'opzione 3.

Se hai sperimentato con i dati passando intorno tra più processi su un piccolo numero di macchine, e avere un po 'di saggezza o di regole empiriche su quali strategie sono robusti, apprezzerei molto il consiglio! (le richieste di chiarimento nelle foto sono benvenute)

Answer 1

Non ho abbastanza rappresentante per spostare questa domanda su programmers.stackexhange.com quindi risponderò qui.

Prima di tutto ti lancio un bel po 'di tecnologie, ognuna delle quali devi dare un'occhiata.

• Hadoop Un quadro di riduzione della mappa. Capacità di acquisire una grande quantità di dati e elaborarli su nodi distribuiti.

• Kafka Un sistema di messaggistica estremamente efficiente. Suggerirei di considerare questo come il tuo messaggio bus.

• ZooKeeper Un sistema distribuito che consente di "individuare" tutti i diversi aspetti del sistema distribuito. Si tratta di un sistema di coordinamento che viene distribuito

• Pub/Sub Messaging

• ∅mq Un'altra libreria socket che permette pub/sub messaging e altri accordi Message Passing N-to-N.

Ora che ho gettato alcune tecnologie su di te, spiegherò cosa farei.

Creare un sistema che consente di creare connettori N. Questi connettori possono gestire Dati/Comando N nel diagramma, dove N è un segnale specifico. Significato se hai 32 segnali puoi configurare il tuo sistema con 32 connettori per "connetterti". Questi connettori possono gestire comunicazioni bidirezionali. Da qui il tuo problema di ricezione/comando. Un singolo connettore pubblicherà i suoi dati su qualcosa come Kafka su un argomento specifico per quel segnale.

Utilizzare un sistema di pubblicazione/sottoscrizione. In sostanza, ciò che accade è che i connettori pubblicano i risultati su un argomento specifico. Questo argomento è qualcosa che scegli. Quindi i processori, l'interfaccia utente, la logica aziendale, ecc. Ascoltano un argomento specifico. Questi sono tutti arbitrari e puoi impostarli come vuoi.

============   =============  =====  ============  ============= 
= Signal 1= < --- > = Connector = < -- = K = --> = "signal 1" ---> = Processor = 
============   =============  = a =  ============  ============= 
             = f = 
============   =============  = k =  ============  ============= 
= Signal 2= < --- > = Connector = < -- = a = --> = "signal 2" ---> = Processor = 
============   =============  = =  ============ | ============= 
             = =     | 
============   =============  = =  ============ | 
= Signal 3= < --- > = Connector = < -- = = --> = "signal 3" --- 
============   =============  =====  ============  

In questo esempio il primo connettore "pubblica" È Risultati a tema "segnale 1" in cui il primo processore è in ascolto su tale argomento. Qualsiasi dato inviato a quell'argomento viene inviato al primo processore. Il secondo processore sta ascoltando sia i dati "signal 2" che "signal 3". Questo rappresenta qualcosa come un'interfaccia utente che recupera segnali diversi allo stesso tempo.

Una cosa da tenere a mente è che questo può accadere attraverso qualunque argomento tu scelga. Un "processore" può ascoltare tutti gli argomenti se lo ritieni importante.