Je vous soumets ma vision sur l'architecture.
Bon évidemment il s'agit d'une réflexion sur le sujet, tout remarque/analyse est bonne.
[Merci de détailler pourquoi]
Je me focalise sur la partie serveur, qui va recevoir les communications et centraliser les actions.
Lexique :
Client : programme lancé sur les postes permettant d'interagir dans l'univers (avec plus ou moins des fonctionnalité suivantes : déplacement, communication instantané, 3D, ...)
Serveur : il s'agit d'une (ou plusieurs machines) utilisé pour contenir des processus (programmes) qui gèrent la communication avec les Clients
Bot : programme qui simule un joueur
Je pars du postulat suivant:
1- Le serveur a toujours raison [idiot comme paradigme, mais il faut choisir entre les clients et le serveur, notez que je dis les clients mais lesquels à raison parmi eux]
2- Minimiser les éléments entre les clients et le serveur (afin de réduire au maximum la latence)
3- Avoir la scalabilité (capacité à continuer de manière normale avec l'augmentation du nombre de personne connecté, bon il faudra voir aussi les limite car suivant les moyen on devra limiter le nombre de machine serveur)
4- Avoir de la redondance (être capable de fonctionner avec la perte d'une partie de l'infrastructure, possibilité de reconnexion rapide, voir le pire bascule complet sur un autre site, bon les délais de bascule varie en fonction du problème)
5- Avoir le moins d'interaction avec la base de donnée [évite des écriture intempestive, relation trop complexe dans la base, éviter les traitements post-séance]
6- Avoir un système d'équité sur l'utilisation de la bande passante réseau (ne pas avoir que le joueur 1 qui répond et agit sans de retour du joueur 2, bref des mécanismes permettant de réguler l'activité de façon équitable [tant que le temps de réponse reste raisonnable pour tout le monde])
7- Gestion des "Bots", ici on rentre plus dans comment gère t-on cela car cela va arriver.
* avoir une API claire avec une identification qu'il s'agit d'un BOT
* avoir la localisation des sources/données/version utilisé pour démarrer le BOT
* Licence qui me semble doit être identique au notre (voir plus ouvert)
* savoir si le Bot est autoriser à s'exécuter dans l'environnement de Prod ou Dev (utile pour les testeurs et claire pour ceux qui font volontairement des erreurs)
* Comment doit-on gérer les personne qui utilise un Bot comme étant un joueur réel?
* Faut-il mettre des différence entre Joueur/Bot?
- Je dirais que oui: concernant la durée d'utilisation un Bot travail 24h, pour un humain s'est impossible
( caractéristiques différentes ?, temps de réponse différent ?)
Ma première idée de séparer les processus de communication serveur pour chaque fonction.
Certaine comme le déplacement sont tout le temps sollicité, à l'inverse l'inventaire auront une activité plus faible.
En séparant les activités, on permet de se séparer d'un étage d'agrégation/compression, et aussi de pouvoir lancer sur une machine différente les processus gourmands en cpu/mémoire ou réseau.
Le problème est que l'on augmente la surface d'attaque sur le serveur.
Le deuxième problème est que certain joueur n'aurait pas la possibilité de communiquer avec plusieurs serveur (problème de firewall), dans ce cas je propose de mettre un processus d'agrégation pour eux (seule eux sont impacté)
J'avais aussi imaginé pouvoir faire une communication en multicast, avantage pour le déplacement des joueurs, pas besoin de renvoyer la même information plusieurs fois. Idée difficile à mettre en place si la partie réseau [que l'on ne maîtrise pas] n'ouvre pas ce type de flux.
Processus:
1- Authentification
2- Gestion de la position
3- Gestion de l'inventaire
4- Gestion des quêtes
5- Gestion des actions en cours [ici on pensera à écrire dans la Base de Donnée l'heure de début, facile ensuite à savoir si l'action est fini en comparant avec l'heure actuelle]
6- Gestion des discussions
7- Éléments présents (décors, object amovible, ...]
8- Caractéristique/Compétence/Faculté/...
9- Identification des noms des personnage (propre à chaque joueur)
X- certaine une fonctionnalité que j'ai oublié
La gestion des positions devrait se faire en plusieurs étapes, avec plusieurs cercles autour du joueur pour connaitre les mouvements des autres.
A savoir que l'on a besoin de savoir si notre voisin le plus proche s'est déplacé d'un mètre, par contre celui qui est à 1km, pas besoin d'avoir l'information à chaque pas (que l'on ne verra pas à l'écran car imperceptible)
Bref, il me semble qu'il faudra un processus pour géré un nombre limité de joueur, et des processus réceptionnant ces info pour gérer les masses de joueurs (et échanger entre eux ces mouvements)
Pour la base de donnée, une simple base de donnée clef/valeur me semble plus "simple" à gérer.
Autre point, certainement information ont une durée de vie très courtes (comme la position), privilégié la mémoire, et d'autre très long (comment l'inventaire), ici on pourrait par exemple se reposer sur un fichier.
Le processus d'authentification aura pour fonction de démarrer/attribuer les processus utilisable pour le client (avec un identifiant/clef pour chaque processus)
La redondance des processus, un primaire et un secondaire (le primaire donnant les info au secondaire), en cas de crash du premier, le secondaire devient primaire et un processus de supervision relance un autre processus (afin d'avoir un deuxième processus actif)
La réplication sur un autre site demandera plus un processus intermédiaire pour copier les info avec durée moyen/longue sur le site distant (aucun intérêt pour les données à durée courte)
@+
AleaJactaEst
PS.:
Fichier PlantUML pour ceux qu'ils veulent reprendre et améliorer.
arch-eclate.txt
