Multithreading (thread per area) per un server MMO, buona idea?

Separare le sale da gioco in diversi thread è un buon inizio. È consigliabile andare oltre. Quanti dati sono condivisi tra le stanze? Se vengono condivisi pochi dati, è possibile progettare un'API interna (ad esempio chiamate di servizio o tramite un database condiviso) per condividere i dati tra le stanze e fare in modo che ogni stanza sia un processo separato. Ciò faciliterebbe le stanze di hosting su macchine diverse.

Forse ogni stanza può ascoltare il proprio endpoint (indirizzo IP + porta). Quando un giocatore entra in un portale per spostarsi dalla stanza A alla stanza B : process A passa l'oggetto giocatore per elaborare B tramite l'API e il canale interni e contemporaneamente il client di gioco del giocatore apre una nuova connessione all'endpoint in cui il processo B è in ascolto.

I thread possono essere utilizzati per migliorare la concorrenza all'interno di una stanza: la comunicazione con i client di gioco può essere gestita da un pool di thread, separati dal ciclo di gioco principale. La fisica può avere il suo thread. AI può avere il suo thread.

Penso che questa potrebbe essere un'architettura valida. La più grande fonte di bug nelle applicazioni multithread è l'accesso condiviso ai dati. Quindi, quando le stanze hanno poca o nessuna comunicazione tra loro e hanno bisogno di poco o nessun accesso ai dati non esplicitamente posseduti da loro, allora sembrano l'ovvio candidato per le unità di parallelizzazione.

Se sei preoccupato della eccessiva parallelizzazione, tieni presente che di solito è più facile ridurre il threading piuttosto che introdurne di più. Quando si scopre che ti piacerebbe gestire le stanze in modo sequenziale dopotutto, di solito non è molto importante uno sforzo di refactoring per cambiare il tuo metodo di aggiornamento per elaborare più stanze in un ciclo invece di uno solo. D'altra parte, tagliando un'architettura single-threaded in una multi-threaded dopo che il fatto può finire rapidamente in un caos buggy.

A proposito, potresti voler organizzare il tuo codice attorno a ThreadPool classifica e passa Task s dove ogni attività consiste nell'esecuzione di un singolo aggiornamento-tick per una singola stanza. Il ThreadPool può essere configurato per utilizzare un numero specifico di thread. Non dovresti impostarlo più alto del numero di core (virtuali) della CPU. Quando si assegnano più attività rispetto ai thread, tali attività verranno accodate ed elaborate non appena viene terminata una discussione. Ciò significa che puoi lasciare la pianificazione degli aggiornamenti al framework.

Informazioni importanti sul multithreading:

• Il multithreading può essere supportato dall'hardware : fino al numero massimo di thread simultanei supportati da una determinata CPU , sarete in grado di ottenere un throughput molto più alto.
• Tuttavia, alcuni risultati sperimentali mostrano che mentre si ottiene un throughput più alto in totale, il throughput individuale di ciascun thread potrebbe diminuire leggermente .
• Se si dispone di più thread attivi rispetto a quelli supportati dall'hardware della CPU in modo nativo, l'utilità di pianificazione del thread del sistema operativo dovrà utilizzare il time slicing e fare in modo che alcuni thread in eccesso attenda di volta in volta. Windows ad esempio utilizza un algoritmo di pianificazione basato su priorità preventiva. Cambiare i contesti dei thread consuma un piccolo sovraccarico.
• C'è un limite tecnico al numero massimo di thread che puoi eseguire . Su un Windows a 32 bit sei limitato a 2000 thread. Su Windows a 64 bit puoi sperare fino a 50.000 thread (sotto linux, i limiti saranno simili ). Ma questo limite diminuirà ulteriormente a seconda delle risorse consumate da ciascun thread.

Conseguenze per la tua architettura:

• Il threading della stanza sarà molto più piacevole per l'utente: meglio una camera singola leggermente più lenta ma senza ritardi, piuttosto che un singolo thread ultraveloce che consente agli utenti di sperimentare ritardi dovuti a tutte le altre stanze che devono essere elaborate in modo sequenziale maniera !
• In un MMO, la maggior parte delle volte i tuoi thread attenderanno l'I / O di rete. Questo naturale effetto di attesa (commutazione volontaria) garantisce un migliore utilizzo della CPU e oltre compensa il sovraccarico degli switch di contesto.
• Tuttavia, il tuo numero massimo di camere sarà limitato . E questo limite è valido anche se le camere più vecchie non sono utilizzate. Se stai pensando a numeri molto lontani, le cifre menzionate, allora ok. Altrimenti dovresti considerare un'altra alternativa.

Alternative:

Il tuo approccio al multithreading è un ottimo inizio. Ma invece di allocare un thread in ogni singola stanza, potresti considerare di avere un thread che gestisce più stanze. Quanti potrebbero essere determinati nella configurazione o calcolati dinamicamente in fase di esecuzione.

Un'altra domanda è come gestisci l'I / O. Le stanze gestiscono le loro connessioni utente? Se no, è meglio allocare più thread per l'I / O e disaccoppiarlo con un'architettura basata su code.

Infine, il problema con le sale multithread è che non puoi scalare oltre il server come MMO della vita reale fare . Quindi è necessario pensare a come ridimensionare tutto questo e come si potrebbe inserire in futuro un gruppo di thread in processi di comunicazione, in modo da poter aggiungere server con processi aggiuntivi per gestire l'aumento del carico di lavoro / connessioni.