Exécution du serveur et du client dans le même processus

Question

Je viens de commencer à travailler avec Lidgren et la mise en réseau pour la première fois, et je me suis rendu compte qu'il est possible d'exécuter à la fois le serveur et le client dans le même processus.

Cette pratique est-elle découragée pour une raison quelconque?

Le contexte

La raison pour laquelle je pose la question est parce que j'ai théorisé que ce concept pourrait me permettre de traiter les modes solo et multijoueur comme un seul et même, ce qui serait très utile.

Suivant ma ligne de pensée, voici la distribution que j'avais en tête:

• Solo - 1 serveur + 1 client dans le même processus. Quelle est la vitesse des communications?
• Multijoueur - Identique au mode solo pour l'hôte + 1 client supplémentaire pour chaque autre joueur.

Le flux d'exécution que j'imagine est pour les clients de recevoir les entrées des utilisateurs et d'envoyer une notification au serveur. Le serveur le valide ensuite et diffuse une action à exécuter par tous les clients. Peu importe qu'il n'y ait qu'un seul client (c'est-à-dire solo) ou plusieurs clients (c'est-à-dire multijoueur).

C'est fondamentalement une question de processus versus thread, les deux ne sont pas trop différents, parfois les threads sont appelés processus légers. La plus grande différence est qu'un processus distinct a son propre espace d'adressage mais il existe d'autres différences (1):

Par processus

• espace d'adressage
• Variables globales
• Ouvrir des fichiers
• Processus enfants
• Alarmes, interruptions et gestionnaires de signaux en attente

Par fil

• Compteur de programme
• Registres
• Empiler
• Etat

Sur la base de ces différences, il pourrait être pratique d'avoir un thread serveur et client dans le même processus afin de pouvoir partager des descripteurs de fichiers et des variables globales. Ce serait un argument pour l'approche «dans le même processus», un autre (petit) argument serait que vous n'obtenez qu'une seule fenêtre contextuelle «Pare-feu Windows» par processus. Un argument en faveur de l'approche des «processus différents» serait qu'une personne peut exécuter plusieurs serveurs sans avoir à exécuter plusieurs clients. Ce serait idéal pour un hôte dédié comme la configuration et c'est une approche que nous voyons couramment dans les tireurs à la première personne.

Maintenant, quant à l'idée d'avoir un processus serveur ou un thread, même pour un jeu hors ligne (et peut-être même pour un seul joueur), c'est une excellente idée qui est beaucoup utilisée dans la pratique. Vous pouvez dire que beaucoup de jeux le font en regardant l'écran de chargement, de petits indices comme «recevoir» le donneront. Il est logique de le faire, car si vous souhaitez créer un mode multijoueur, la plupart des règles du jeu seront régies par le serveur, alors pourquoi ne pas les régir pour un seul joueur? Cela réduit le code que vous devez écrire et offre une séparation plus claire entre le client et le «jeu», ce qui améliorera la qualité de votre code.

Maintenant que diriez-vous de communiquer entre les processus et les threads? La communication entre processus peut se faire de nombreuses façons, par les canaux (nommés), la mémoire partagée, COM, cela dépend vraiment de la technologie que vous utilisez. Cependant, si vous créez un serveur, vous voudrez probablement opter pour une variante de réseau utilisant des sockets et quelque chose comme TCP, c'est bien sûr là que LIDGREN sera utile.

Un grand nombre de ces techniques sont également valables pour la communication croisée. Mais cela dépend encore plus des techniques que vous utilisez. Vous pourriez à nouveau opter pour TCP, mais peut-être un système encore plus simple serait les événements et certains rassemblements, bien que cela puisse rendre votre boucle de jeu non déterministe (2).

Sources

1. Conception et implémentation de systèmes d'exploitation (le livre MINIX), 3e édition par Andrew S. Tanenbaum
2. Fixez votre timestep par Glenn Fiedler: http://gafferongames.com/game-physics/fix-your-timestep/