À la recherche d'une architecture client-serveur

Je vais essayer de lister les différentes possibilités d'architectures pour le projet.
(Note : le client désigne l'application graphique, indépendamment que la personne soit MJ ou joueur.)

1) Un seul serveur, qui peut gérer plusieurs jeux en même temps. L'application cliente connait (dans son code ou fichier externe) l'adresse du serveur.
Avantages : les joueurs (MJ compris) n'ont pas besoin de savoir comment fonctionne le serveur, la connexion au serveur est automatique au démarrage du jeu; possibilité de maintenir une base de données qui peut contenir soit des éléments de jeu (table des sorts, des monstres), soit des statistiques sur les parties jouées (anonymes bien sûr!);
Inconvénients : il faut disposer d'une machine serveur conséquente (performance et bande passante), ou en louer une; si le serveur tombe en rad (ou que sa location n'est plus renouvelée), les joueurs ne peuvent plus jouer; complexité de programmation du serveur;

2) Plusieurs serveurs (lancés par les MJ), des clients qui s'y connectent, et un Master server qui donne aux clients la liste des serveurs.
Avantages : les joueurs ont la liste des serveurs lancés, et peuvent rapidement se connecter à la partie créée par le MJ; le serveur gérera peu de personnes, donc la machine qui l'héberge n'a pas besoin d'être puissante;
Inconvénients : toujours besoin d'un serveur central (bien que plus léger que dans l'architecture précédente); le MJ doit mettre en place le serveur; impossibilité de disposé d'une base de donnée (type MySQL) par serveur (voir plus bas); le MJ doit ouvrir un port pour que les clients puissent s'y connecter (se renseigner sur UPnP);

3) Plusieurs serveurs, et des clients.
Avantages : plus besoin de serveur centrale : indépendance totale
Inconvénients : le clients doivent connaitre l'adresse IP du serveur auquel ils veulent se connecter; le MJ doit toujours ouvrir un port précis
Note : cette architecture peut être facilement combinée avec la précédente. Dans le client, il y aurait la liste des serveurs donnés par le Master server (ou rien s'il est mort), et un champ pour remplir un IP autre.

Le problème avec les trois architectures précédentes est le suivant : le MJ peut tout changer, donc il faudrait créé un protocole réseau (c'est en quelque sorte une langue qui permet aux deux parties de communiquer (exemple : set_hp player1 10)) très lourd, puisque toutes les actions sont possibles pour le MJ.
Solution :
4) Mélanger le code serveur avec le code client MJ, et des clients joueurs qui s'y connectent par l'adresse IP du MJ.
Avantages : indépendance; communication entre le serveur et le MJ immédiate et très simple : pas besoin de réseau, des appels à des méthodes suffisent, puisque la mémoire est partagée;
Inconvénients : comme précédemment (base de données "impossible", problème de l'IP et du port à ouvrir); si le client du MJ crash, le serveur aussi (puisque ce sont le même programme);
Note : pour pallier au problème de l'IP, on peut toujours ajouter un Master server.


Les problèmes liés aux bases de données peuvent être corrigés en utilisant un système de données créé pour l'occasion (exemple : un fichier texte qui contient tous les sorts, formatés de manière à pouvoir être lu par le code).
EDIT : les bases de donnnées type SQLite permettent de ne pas avoir besoin d'un serveur dédié pour la base de données. Les arguments concernant la base de données donnés plus haut sont faux.

Voici le schéma d'une architecture réseau qui peut s'appliquer à un jeu vidéo :


Il faut imaginer qu'il y a une multitude de clients, mais un seul serveur.
En partant du principe qu'on ne peut pas faire confiance aux clients (sinon, la triche est possible), le client n'envoie que des actions au serveur. Ce dernier vérifie que toutes les conditions sont réunies avant de tirer les conséquences de l'action demandée.

Prenons exemple d'un jeu de tir :
Le joueur veut tirer sur un objet, pour le détruire.
Le client envoie au serveur un paquet qui contient l'instruction "tirer". Le serveur traite l'information : il vérifie que le joueur est encore vivant (ça parait bête, mais ce genre de tests est (souvent) nécessaire), qu'il a encore des balles pour l'arme actuel, etc… Enfin, si tous les tests sont validés, alors le serveur fait en sorte qu'une balle soit tirée, et que l'objet est détruit si la visée était correcte.
Un fois cela fait, le serveur envoie aux différents clients que tel objet a été détruit. Ceux ci mettent à jour leur liste d'objet en local, et modifient l'affichage.

À aucun moment les clients peuvent modifier les données du jeu.
Si un client le fait en local, alors les autres joueurs ne seront pas affectés. Seul l'affichage du joueur qui a modifié ses données verra son affichage modifié. Et son affichage ne correspondra plus à la "réalité" (les "vraies" données, celle du serveur), mais cela n'influencera pas le jeu en lui même.
Un client ne pourra pas modifier les données des autres joueurs, ou du serveur, puisque la communication client -> serveur n'est basé que sur des instructions qui appartiennent au jeu, comme se déplacer, lancer un sort, ou même parler. La difficulté est la rédaction d'un protocole complet et "sécurisé".

En bref, les données de jeu sont situées sur le serveur. Lui seul peut les modifier directement.
Les clients envoient des actions, qui sont traitées par le serveur, pour influencer sur le jeu.
En revanche, au niveau du client, on retrouve bien sûr certaines données du jeu, qui permet aux clients de les afficher. Mais ces données seront toujours considérées comme non sûres.