Massive Software Simulator Architecture [chiuso]

Ho lavorato su esattamente 1 applicazione di simulazione, con requisiti più deboli (cioè dovevamo avere tutto l'aggiornamento 1 / s). Sentitevi liberi di prendere questo con un granello di sale, ma è un posto dove iniziare. Penso che avrete difficoltà a realizzare i vostri obiettivi di temporizzazione con i sistemi operativi azionari. Posso solo evidenziare alcune lezioni apprese:

• A volte i requisiti sono sovradicati
  • Esempio: hai intervalli di 10ms con attività eseguite in +/- 2ms, potrebbe essere abbastanza buono per avere quella velocità complessiva ma la versione reale è più simile a 100ms con attività svolta in +/- 20ms. Stessa tariffa, ma molto più ragionevole da progettare per.
  • Esempio: probabilmente i tuoi client esterni non hanno gli stessi requisiti quasi in tempo reale della tua applicazione
• Devi essere in grado di interrompere l'elaborazione in anticipo, o interrompere l'estrazione dalla coda se sei vicino alla fine della finestra o se annulli effettivamente il lavoro esistente
• A seconda di cosa viene simulato, il modello di attore o un approccio simile potrebbe essere la scelta migliore per il tuo progetto generale

Nella simulazione su cui stavo lavorando, stavamo modellando le comunicazioni con i dispositivi di segnale e le torri e gli effetti dei dispositivi che si muovevano quasi in tempo reale. Considerando il numero di dispositivi che dovevamo simulare non potevamo dedicare un thread completo a ciascun attore (dispositivo e tower), ma potremmo avere un numero finito di thread che lavorano contro il corpus per elaborare i messaggi fino al tempo di simulazione corrente- francobollo.

L'unica cosa che consiglierei è di iniziare con una fondazione stabile e sottoporre a stress la simulazione. Sono quegli stress test che ti costringono a prendere decisioni difficili su dove poter scambiare l'assoluta fedeltà con qualcosa che ti dà lo stesso effetto complessivo. Ti garantisco che nessun utente umano noterà la differenza tra 10ms e 100ms.

Qualsiasi simulazione è un compromesso tra fedeltà al modello di lavoro e qualcosa che lo avvicina.

Inoltre, non prendere le decisioni sulla memoria condivisa rispetto a pipe o socket inizialmente. Concentrati sul comportamento principale.

Qualcosa che sto imparando con alcuni dei miei sforzi più recenti è che a volte un approccio shared nothing fornisce la migliore scalabilità complessiva. Per avere un'idea dell'approccio dei microservizi, si avrebbe un'architettura in cui un servizio di simulazione fornisce l'intero ambiente per gli eventi di cronometraggio ad alta precisione. Il trucco consiste nel partizionare l'ambiente in modo sicuro negli ambienti più piccoli. Questo può essere fatto per veicolo o per spazio aereo.

Abbiamo le seguenti note:

• Il tuo codice critico soddisfa i requisiti
• Non tutto ha i requisiti temporali rigorosi (in base ai tuoi commenti sopra e sotto)
• Le comunicazioni socket sono lente, anche sulla stessa macchina
• La memoria condivisa può essere complicata e ha ancora costi di serializzazione, ma ti limita a una macchina

Essenzialmente, per far lavorare insieme più nodi di simulazione è necessario pacchettizzare e trasmettere lo stato ai nodi interessati a intervalli regolari. Hai bisogno che quella trasmissione sia veloce e densa . Le opzioni sono:

• named pipe, abbastanza alta velocità, alta affidabilità
• Pacchetti UDP, abbastanza veloci, i pacchetti possono essere divisi da router con una dimensione massima sicura di circa 1134 byte di payload.
• Pacchetti TCP, più lenti, ma molto più affidabili

Le comunicazioni possono essere eseguite in modo asincrono invocando eventi nel nodo ricevente. Nel mio caso abbiamo optato per pacchetti UDP poiché l'intero sistema era destinato ad essere eseguito in una sottorete. Abbiamo anche utilizzato un formato di trasmissione binario come i buffer del protocollo di Google per massimizzare le informazioni per byte.

Nel mio progetto, la maggior parte delle simulazioni potevano essere eseguite su una macchina, ma il software di visualizzazione del sensore veniva tipicamente eseguito in remoto.

In questo caso è stato un trade-off di quanto frequentemente abbiamo aggiornato il sistema esterno e la quantità di dati. Ogni nodo aveva una coppia di socket aperti, uno per l'invio e uno per la ricezione.

Nella maggior parte dei casi siamo riusciti a proiettare matematicamente il nostro movimento con una precisione tale da non consentire l'osservazione delle correzioni di percorso ricevute e la simulazione era ancora valida.

Ma ancora una volta, un approccio come questo deve essere testato rispetto ai criteri conosciuti per il tuo sistema.