L'architecture des MMORPGs
Congestion et pannes
La fiabilité est un critère très important dans la popularité d'un jeux milti-joueurs en ligne tel qu'un MMORPG. La disponibilité et la fiabilité doit être asssurée à tout prix, sous peine de lourde retombées économiques. Pour exemple, tout un pool de serveur de World of Warcraft devint inaccessible pendant quelques heures. Les pertes furent estimées à 100 000$/heure. Cette section présente les mécanismes pour palier aux pannes et aux congestions, les 2 premiers facteurs d'indisponibilité d'un jeu.
Comme nous l'avons vu, un MMORPG peut rassembler des dizaines de millions de joueurs. Même si le monde est distribué sur un pool de serveurs de jeu, il se peut qu'un pic de joueurs se produisent sur un serveur particulier et le sature. Il faut alors que ce serveur puisse se libérer d'une partie de sa charge de travail. En pratique, le serveur congestionné va le signaler au master. Il pourra alors diviser la zone du monde qui lui est attribué en 2 pour en déléguer la charge à un serveur faiblement actif ou un serveur de réserve (qui lui sera indiqué par le Master) afin de diminuer le nombre d'objets à gérer. Le diagramme suivant montre comment cela est réalisé.
Nous avons ici un serveur S1 congestionné qui va dédier une partie de sa zone à un serveur S2. Il commence par désigner la zone à déleguer, puis en notifie S2. Il commence alors à transferer les données du jeu relatives à la zone considéré vesr S2.
Si pendant le temps de transfert des données entre S1 et S2, un joueur ou objet émet une action, celle-ci est aussi transferée à S2 qui l'ajoute à une liste d'attente. Ala fin du transfert, S1 confirme le split de sa zone à S2 qui devient alors opérationnel.
S2 notifie alors tous les objets connectés dans la zone dont il vient d'obtenir la gestion qu'il est maintenant leur nouveau serveur de jeu. Les clients peuvent se connecter et souscrire aux notifications selon le pattern Publish/Subscribe comme vu dans la section précédente. S2 exécute alors toutes les actions de la liste d'attente et publie les résultats.
Du point de vue de l'utilisateur, son gameplay aura peut être été perturbé pendant quelques secondes, mais de façon transparente, il a été redirigé vers un nouveau serveur et aucune interruption de jeu n'a été constatée.
Du fait du nombre important de serveurs de jeu impliqués dans l'architecture d'un MMORPG, il n'est pas rare que l'un d'entre tombe en panne. Pour palier aux pannes de serveurs de jeu (les plus critiques qui nous intéresse!), il existe une solution: le mirroring. Le monde est distribué sur des paires de serveurs: un serveur primaire Sp et secondaire Sb par zone. Sb souscrit à Sp pour les évènements sur toute sa zone. Donc Sp notiefira tout le temps Sb avant tout le monde! De plus il l'informera aussi des prises et relâchements de locks. Ainsi, à n'importe quel instant, Sb est la copie conforme de Sp.
Dès que le Master détecte que Sp est en panne, il demande à Sb de prendre le relais. Sb réalise alors les dernières étapes du diagramme ci-dessus (Sb contient toutes les données de jeu, y compris les évènements en cours d'exécution): Il notifie tous les objets de la zone qu'il est le nouveau serveur de jeu. Ces derniers se connectent et souscrivent à Sb qui devient opérationnel.
Nouveau Serveur
Un MMORPG a une certaine durée de vie. Afin d'étendre cette durée de vie au maximum, et de rendre le jeu plus rentable, le monde original est souvent élargi avec des extensions, des MODs ou autres. Cela nécessite en pratique l'ajout de nouveaux serveur qui doivent s'intégrer à l'architecture facilement et de façon transparente pour les joueurs (il est hors de question de fermer le jeu pour ça!). Ici encore, le pattern Publish/Subscribe va nous être bien utile. En fait c'est lui qui va faire tout le boulot. Prenons le cas d'une architecture avec 7 serveur de jeu actif et un 8ième qui doit être mis en service tels que montré sur la figure suivante.
Les zones de frontière (à distance R) entre le nouveau serveur et ses futures voisins sont modélisées en couleur. Afin que des objets du jeu puissent commencer à arpenter cette nouvelle zone, il faut que les serveurs 1, 2, 3, 6, et 7 aient connaissance du serveur 8 et vice et versa. Ce dernier va donc demander au Master la liste de ses voisins. Il souscrit aux serveurs 1, 2, 3, 6, 7 pour les zones de frontières. Ces derniers vont en même temps être averti de l'existence du serveur 8. Il vont donc chacun souscrire pour leur zone de frontière avec le serveur 8. Ces échanges sont résumés dans le diagramme ci-dessous.
Le gameplay des joueurs évoluant à la frontière des serveurs 1, 2, 3, 6, 7 n'aura pas été alteré par l'ajout du nouveau serveur. On peut même imaginer qu'ils soient passés sans s'en rendre compte dans la nouvelle zone proposé par ce nouveau serveur, celle-ci apparaissant soudainement au détour d'un chemin...