Pensées asynchrones

Avoir un système pleinement distribué, voilà le rêve de tout architecte de MMORPG. Pour l'instant, AdH est mono-processus et mono-thread (mono-processus léger, que me dit mon encyclopédie communautaire préférée). Cela n'empêche heureusement pas d'y réfléchir.

Faisons le tour de quelques composants génériques et de la manière de les distribuer:

La gestion de compte
Autant l'authentification et le chargement des données personnelles peuvent être totalement distribués, autant il va quand même falloir éviter de permettre à un joueur de se connecter sur deux serveurs simultanément, sauf si le don d'ubiquité est partie intégrante du jeu. Si l'on veut un système centralisé, il faut que le composant ne fasse effectivement que ça. Même dans le cas de Wow et ses 9 millions de comptes (allez, arrondissons à 10 millions), on arrive si chacun des comptes se connecte une fois par jour (et on en est loin!) à 115 transactions par seconde, ce qui est parfaitement supportable pour une base de données digne de ce nom (quand on a 10 millions de comptes, on ne fait pas tourner sa gestion des comptes sur un vieux Pentium au fond du garage, de toutes manières). Mais, imaginons un succès fou (ou que le vieux Pentium au fond du garage batte de l'aile), on peut imaginer une partition simple, basée par exemple sur la première lettre du compte. Une base de données pour les joueurs de a à d, une deuxième pour le joueurs de e à j, et ainsi de suite. On diminue ainsi la charge pour chacune des machines (avec pourquoi pas un transfer de compte des lettres les plus utilisées vers les moins utilisées, et une propagation vers les serveurs principaux des adresses des serveurs correspondant aux lettres), par contre on augmente la complexité du réseau (chacun des serveurs principaux doit pouvoir se connecter à chacun des serveurs de comptes).

L'inventaire
Même problème: afin de s'assurer que le joueur ne profite pas d'une gestion de l'inventaire décentralisée pour échanger le même objet plusieurs fois, il faut s'assurer qu'il n'existe qu'un endroit où la transaction se fait. L'on peut imaginer un système de roaming, où l'inventaire du joueur le "suit" de serveur en serveur. Efficace, mais complexe, et surtout ennuyeux dès qu'un échange se fait entre des joueurs qui ne sont pas sur le même serveur (quand on a un univers pleinement distribué, c'est quand même dommage d'en faire des petits mondes indépendants!). Le même système à base d'inventaires distribués sur la première lettre du nom (ou les 2 premières lettres, ou plus, d'ailleurs) devrait être suffisamment efficace et relativement simple pour de grosses charges. C'est d'ailleurs fondamentalement une table de hachage!

Le monde
C'est là que ça se complique! Le monde peut être découpé en zones, façon Eve Online, qui gère ainsi un seul immense univers cohérent. Dans les mondes continus, un serveur peut gérer une surface donnée, et recevoir des données des autres serveurs pour afficher les joueurs "fantômes", c'est à dire gérés par d'autres serveurs mais visibles des joueurs locaux, parce que suffisamment proches de la frontière virtuelle entre deux serveurs. Lorsque le joueur franchit cette frontière, le serveur le passe à un autre serveur.
Ces deux techniques, déjà complexes, souffrent cependant lorsque trop de joueurs se dirigent vers le même endroit: le même serveur se retrouve à gérer énormément de joueurs, alors que d'autres serveurs sont presque totalement déserts. Et faire des zones plus petites, ou qui changent de taille en fonction du nombre de joueurs, devient extraordinairement compliqué, et les communications inter-serveurs explosent.

Le flux
La plus grande difficulté, en architecturant ce type de système distribué est de maintenir la cohérence. Par exemple, un serveur recevant une demande de connexion va envoyer une demande d'authentification à un serveur de compte, mais quand la réponse lui revient, le client s'est déjà déconnecté, ou s'est authentifié sous une autre identité.

Et toute faiblesse du système sera impitoyablement exploitée par les joueurs!

Et c'est pour cela qu'on se contentera pour l'instant d'un AdH mono-processus et mono-thread!