Vecchi thread I/O per modello client o pattern reattore NIO?

Question

Sto scrivendo la rete sul lato server di un gioco multiplayer. Il gioco è un gioco di ruolo e ha la capacità massima assoluta di 2000 giocatori, ma praticamente raggiungerà un massimo di circa 300 giocatori, anche se potrebbe essere più alto o più basso. Per il tempo più lungo, ogni volta che dovevo fare networking dove coinvolgeva molti clienti, mi sono attenuto a NIO perché non richiedeva l'uso di centinaia di thread. Recentemente, mi sono imbattuto in una presentazione di PowerPoint in cui descriveva i due modelli in dettaglio, e ha quasi fatto sembrare il modello thread-per-client superiore a NIO. Ho anche trovato dei posti in cui afferma che il vecchio IO può effettivamente superare anche NIO.

Il PowerPoint può essere trovato qui (è un po 'vecchio): http://www.mailinator.com/tymaPaulMultithreaded.pdf.

Non ho ancora scritto alcun contenuto, quindi non sarebbe un problema per me iniziare all'inizio se dovessi cambiare il mio intero design di rete. Non sono sotto pressione per tempo. Inizialmente, stavo progettando un'implementazione del modello di reattore con NIO (selezionare un evento, inviare un gestore per gestire l'evento).

Ulteriori informazioni possono essere trovate qui: http://en.wikipedia.org/wiki/Reactor_pattern

mio intero attuazione reattore è progettato per utilizzare un singolo filo. Da quando ho letto che il vecchio IO può sovraperformare, in realtà mi ha messo in un dilemma. Non voglio progettare un complicato sistema NIO che utilizza più thread solo per sfruttare appieno tutta la potenza della CPU, ma mi viene anche l'idea che una singola applicazione usi 300+ thread. Qual è il design giusto per il mio scopo? Il vantaggio del thread per client è che utilizza veramente tutta la potenza della CPU per natura, ma allo stesso tempo impantanare il sistema. Per non parlare, la dimensione dello stack di un singolo thread occupa molta memoria (quando moltiplicata di un paio di centinaia di volte). Dovrei attenermi al modello del reattore?

So che questa domanda è un po 'ambigua, ma sento che ho bisogno di fare una domanda specifica per la mia situazione, perché non sono riuscito a trovare una domanda su questo sito né un sito web in cui risolva un problema del mio tipo. Ce n'era una su un gioco, ma il gioco era pensato per gestire decine di migliaia di giocatori.

Grazie mille! Se hai bisogno di chiarimenti, chiedi!

Answer 1

Non voglio progettare un complicato sistema NIO che utilizza più thread solo per sfruttare appieno tutta la potenza della CPU, ma mi viene anche l'idea che una singola applicazione usi 300+ thread. Qual è il design giusto per il mio scopo?

Le nostre JVM corrono con più di 500 thread continuamente (in questo momento si trovano a ~ 700) con picchi negli anni 1000. Non vedo alcun motivo per pensare che 800 thread siano in qualche modo "rabbiosi" degni. Comincerei a preoccuparmi quando raggiungerai 10.000 thread (come numero di un parco giochi) - forse meno se stai usando sotto i 32 bit. Sicuramente dovrai allocare più memoria mentre entri nei 1000 ma qualsiasi cosa sotto i thread da 1k non dovrebbe essere un problema. Ecco una buona pagina su thread creation numbers.

NIO è il più efficiente se si dispone di un numero di connessioni grande con IO infrequente. Risolve un sacco di problemi quando si tratta di comunicazione asincrona e ci sono cose che puoi fare con NIO che il "vecchio IO" non può fare da un punto di vista funzionale (canali interrompibili e IO non bloccanti, per esempio) ma il gestore di thread singolo è un modello molto più semplice e non mi sorprende che possa superare le implementazioni NIO in molte configurazioni. Con NIO stai facendo molte operazioni nel codice Java che sono fatte per te nella JVM o persino nel kernel nel codice nativo.Il multiplexing degli stream e la gestione dell'IO pronto sono tutte cose che si ottengono "gratuitamente" (in termini di complessità) con il modello "vecchio IO".

Vorrei mantenerlo semplice e seguire il modello thread-per-client fino a quando non si hanno buone ragioni per prendere il colpo di complessità.