Esecuzione del server e del client nello stesso processo

Domanda

Ho appena iniziato a lavorare con Lidgren e il networking per la prima volta e sono arrivato alla conclusione che è possibile eseguire sia il server che il client nello stesso processo.

Questa pratica è scoraggiata per qualche motivo?

Contesto

Il motivo per cui lo sto chiedendo è perché ho teorizzato che questo concetto potrebbe permettermi di trattare sia la modalità giocatore singolo che la modalità multiplayer come una cosa sola, il che sarebbe molto utile.

Seguendo la mia linea di pensiero, questa è la distribuzione che avevo in mente:

• Giocatore singolo - 1 server + 1 client nello stesso processo. Quanto sono veloci le comunicazioni?
• Multigiocatore - Come il giocatore singolo per l'host + 1 client adizionale per ogni altro giocatore.

Il flusso di esecuzione che sto immaginando è per i clienti di ricevere l'input dell'utente e inviare una notifica al server. Quindi il server lo convalida e trasmette un'azione che deve essere eseguita da tutti i client. Non dovrebbe importare se esiste un solo client (ad esempio giocatore singolo) o più client (ad esempio multiplayer).

Questo è fondamentalmente un processo rispetto alla domanda di thread, entrambi non sono troppo diversi, a volte i thread sono chiamati processi leggeri. La differenza più grande è che un processo separato ha il suo spazio indirizzo ma ci sono altre differenze (1):

Per processo

• spazio degli indirizzi
• Variabili globali
• Apri file
• Processi secondari
• In attesa di allarmi, interrupt e gestori di segnali

Per filo

• Contatore di programma
• registri
• Pila
• Stato

Sulla base di queste differenze potrebbe essere utile avere un thread client e server nello stesso processo in modo da poter condividere handle di file e variabili globali. Questo sarebbe un argomento per l'approccio "nello stesso processo", un altro (piccolo) argomento sarebbe che si ottiene solo un pop-up "Windows Firewall" per processo. Un argomento per l'approccio del "processo diverso" sarebbe che una persona può eseguire più server senza dover eseguire più client. Questo sarebbe l'ideale per un host dedicato come il set-up ed è un approccio che comunemente vediamo negli sparatutto in prima persona.

Ora, per quanto riguarda l'idea di avere un processo server o thread anche per il gioco off-line (e forse anche per single-player) questa è una grande idea che viene usata molto nella pratica. Puoi dire a molti giochi di farlo guardando la schermata di caricamento, piccoli suggerimenti come "ricezione" lo daranno via. È logico farlo dal momento che se hai intenzione di creare un multigiocatore, la maggior parte delle regole di gioco saranno governate dal server, quindi perché non averle per il giocatore singolo? Ciò riduce il codice che devi scrivere e offre una più chiara separazione tra client e "gioco" che migliorerà la qualità del codice.

Che ne dici di comunicare tra processi e thread? La comunicazione tra processi può essere fatta in molti modi, (named-) pipe, memoria condivisa, COM, dipende davvero dalla tecnologia che stai utilizzando. Tuttavia, se stai creando un server, probabilmente vorrai scegliere una variante di rete che utilizza socket e qualcosa di simile a TCP, ovviamente LIDGREN ti tornerà utile.

Molte di queste tecniche sono valide anche per la comunicazione cross thread. Ma questo dipende ancora di più dalle tecniche che stai utilizzando. Potresti andare di nuovo con TCP, ma forse un sistema ancora più semplice sarebbe eventi e alcuni marshalling, anche se questo potrebbe rendere il tuo ciclo di gioco non deterministico (2).

fonti

1. Progettazione e realizzazione di sistemi operativi (il libro MINIX), 3a edizione di Andrew S. Tanenbaum
2. Correggi il tuo timestep di Glenn Fiedler: http://gafferongames.com/game-physics/fix-your-timestep/