Un server socket e un server di gioco devono essere processi separati?

Supponiamo un semplice gioco client / server standard. Per il server, vale la pena disporre di un processo separato che ascolti connessioni e messaggi dai client e invii i dati tramite socket locali o stdin a un altro processo che esegue il server di gioco effettivo?

L'altra opzione sarebbe quella di fare entrambe le cose in un unico processo. Accodare i messaggi in arrivo ed eseguirli nell'ordine corretto non dovrebbe esserci un problema di arresto.

Mi chiedo se le risorse extra per separare le due "attività" valgono davvero la pena. Come dovrei decidere? Mi piacerebbe sentire eventuali pro / contro.

Dal punto di vista della progettazione API, quando si decide se creare più programmi di comunicazione separati o solo uno, la domanda è: ciascun programma può funzionare in modo significativo senza gli altri? La risposta varierà in base al progetto e alle preferenze.

Se non possono , non vale la pena pensarci. Chiaramente sono così fortemente collegati che non sono processi realmente separati.

Se possono , e puoi vedere te stesso voler inserire componenti diversi per sostituirli in futuro, un'astrazione del processo fornita dal sistema operativo potrebbe essere di aiuto.

Quanto più aiuta dipende il resto del tuo stack tecnologico però. Ad esempio, Erlang modella già internamente le cose come processi, quindi non trarrai alcun vantaggio concettuale dalla divisione in processi OS. A meno che tu non stia pensando di riscrivere quelle parti del server in una lingua diversa. I componenti interni di un programma C ++ sono in genere accoppiati molto più stretti e quindi possono essere più difficili da sostituire, quindi suddividerli in diversi processi del sistema operativo può farti risparmiare lavoro in seguito se puoi prevedere tali riarrangiamenti.

vale la pena avere un processo separato che ascolta le connessioni e i messaggi dai client e invia i dati tramite socket locali o stdin a un altro processo che esegue il server di gioco effettivo?

Per rispondere se vale la pena, devi prima chiederti, qual è il problema che stai cercando di risolvere aggiungendo un servizio di accodamento dedicato. Se risolve quel problema, allora vale la pena; se non risolve un problema o se non hai un problema da risolvere, probabilmente non lo è.

Vediamo alcuni motivi per cui alcuni server utilizzano un'architettura multilivello:

1. Bilanciamento del carico: il bilanciamento del carico ha senso se si desidera distribuire il carico di lavoro su più macchine di lavoro. Se il tuo programma ha colli di bottiglia che vuoi risolvere semplicemente avendo più processi di lavoro simultanei sulla stessa macchina, allora è meglio nel lungo termine risolvere effettivamente il collo di bottiglia, ma come soluzione a breve termine, la generazione di processi di lavoro potrebbe essere pratica.
2. Separazione dei privilegi - Forse non vuoi che una violazione della sicurezza nel tuo server di chat ottenga automaticamente l'accesso al tuo server di gioco o viceversa. Se il tuo server di gioco è separato dal tuo server di chat in-game, puoi configurare il tuo server di gioco e il tuo server di chat in modo che vivano in un dominio di sicurezza separato (ad es. Come utente diverso, con privilegi di accesso diversi, limiti di processo diversi, ecc.).
3. Zero downtime upgrade - se si desidera ottenere zero downtime upgrade, è necessario disporre di più livelli e configurare il sistema in modo tale che quando si rimuove un server per la manutenzione, le sue richieste verranno reindirizzate agli altri server nello stesso livello per garantire un continuo servizio.
4. Limite di interruzione: se si raggiunge il limite del socket, il limite del descrittore di file, un blocco dell'interprete globale e così via, è possibile aggirare tale limite eseguendo più processi. Un altro modo per risolverlo è modificare il limite, ma non è sempre facile in quanto potrebbe essere necessario ricompilare il kernel o potrebbero esserci implicazioni sulla sicurezza o sulle prestazioni.
5. Limitazione della perdita di risorse: si desidera scrivere un software che non perde risorse, ma anche in linguaggi completamente gestiti, questo è estremamente difficile in processi di lunga durata e, peggio ancora, è difficile replicarlo in un ambiente di sviluppo. Un'architettura a più livelli ti consente di uccidere e rigenerare i server di gioco dopo un certo periodo di tempo o un numero di richieste per limitare i danni causati da perdite di risorse, senza interrompere il servizio.

Sono d'accordo con il maniaco del cricchetto. Finché hai un singolo server di gioco, non vale la pena.

Tuttavia, questa architettura potrebbe rivelarsi utile quando è necessario ridimensionare in orizzontale. Quando un gameserver non è più sufficiente ed è necessario distribuire il gioco su più gameserver per motivi di prestazioni, l'architettura "socket server" potrebbe essere facilmente adattata per trasformare il server socket in un bilanciamento del carico che instrada automaticamente le connessioni a uno dei tanti back-end server.

Ma quando non sei sicuro di averne mai bisogno, è probabilmente troppo ingegneristico sviluppare due applicazioni server separate a questo punto.

Probabilmente no, la maggior parte delle lingue ha socket asincroni che consentono di utilizzare più connessioni contemporaneamente senza bloccare mentre i dati sono in attesa. Questo sposta la parte "socket server" sul sistema operativo / kernel.

Con un server socket esplicito dovrai sostenere il costo di alcune copie extra mentre passi i dati attraverso il socket locale; una cosa che ucciderà la scalabilità è copie extra dove non ne hai bisogno.