Vers un système d arbitrage décentralisé pour les jeux en ligne

Transcription

1 Vers un système d arbitrage décentralisé pour les jeux en ligne Maxime Véron, Olivier Marin, Sébastien Monnet, Zahia Guessoum Laboratoire d Informatique de Paris 6 / CNRS Université Pierre et Marie Curie Paris, France prénom.nom@lip6.fr Résumé L arbitrage des jeux massivement multi-joueurs (MMOGs) repose actuellement sur des architectures centralisées, qui facilitent la détection de la triche mais empêchent les MMOGs de passer à l échelle. La centralisation limite la taille du monde virtuel ainsi que le nombre de joueurs qui y évoluent. Nous montrons dans cet article qu il est possible de concevoir un arbitrage pair à pair hautement efficace, même à grande échelle, aussi bien en terme de performance que de prévention de la triche. Nos simulations montrent que notre solution permet de gérer au-delà de nœuds tout en détectant plus de99,987% des tentatives de triche sur des dizaines de millions de requêtes d arbitrage. Mots-clés : jeux massivement multi-joueurs ; arbitrage décentralisé ; système de réputation 1. Introduction Les jeux massivement multi-joueurs en ligne (Massively Multiplayer Onling Games - MMOGs) visent à rassembler un nombre potentiellement infini de joueurs dans un même univers virtuel. Pourtant, aucun MMOG existant ne passe à l échelle correctement. Par tradition, ces derniers reposent sur des architectures client/serveur (C/S) qui imposent une limite sur le nombre de joueurs (avatars) et sur les ressources qui peuvent coexister dans un monde virtuel [9]. Une des principales raisons à cette limitation repose sur une hypothèse : la décentralisation inhibe la protection contre la triche. La détection de la triche est un élément clé du succès d un jeu. Un jeu où les tricheurs arrivent systématiquement à prendre le dessus sur les joueurs qui suivent les règles va rapidement devenir impopulaire auprès de sa communauté. Pour cette raison, il est important pour les fournisseurs de jeux d intégrer des protections efficaces contre la triche dans leurs logiciels. Les architectures C/S favorisent le contrôle des calculs, mais sont en pratique loin d être à l épreuve de la triche. Une version récente d un MMOG populaire, Diablo 3, a été victime d un piratage qui a causé son arrêt pendant un jour entier [1]. La triche et les problèmes qu elle soulève pour les approches centralisées et décentralisées seront évoquées plus en détails en section 2. Cet article présente une architecture passant à l échelle pour l arbitrage des jeux ; la surveillance du jeu est à la fois efficace et fiable. Notre approche utilise un réseau logique pair à pair (P2P) pour déléguer l arbitrage du jeu aux nœuds joueurs du réseau. elle se base sur un système de réputation pour juger de l honnêteté des nœuds et ensuite écarter les arbitres et les joueurs malhonnêtes. Un processus indépendant teste les nœuds avec de fausses requêtes afin d accélérer l évaluation des réputations. Notre contribution principale est une approche d arbitrage décentralisée pour les jeux vidéo (voir section 3) qui gère facilement plus de nœuds et permet de détecter plus de 99,9% des tentatives de triche, même dans des conditions très défavorables (voir section 4).

2 2. L intérêt des architectures décentralisées pour le monde du jeu vidéo Le passage à l échelle est une préoccupation essentielle pour les jeux vidéos en ligne : la génération actuelle de MMOGs souffre de la limite imposée sur la taille et sur la complexité des univers virtuels. Dans le cadre plus particulier des jeux de rôles (MMORPGs), la tendance est de se réunir en équipes de joueurs pour améliorer les chances de succès contre les autres joueurs ou contre le jeu lui-même. Le fait de ne pas pouvoir se connecter sur un même serveur est une cause fréquente de frustration pour les équipes de joueurs. Les problèmes liés au passage à l échelle dans les jeux en ligne actuels sont principalement dûs à leurs infrastructures C/S [9]. Pour compenser cela, les fournisseurs de jeux créent de multiples univers de taille réduite : soit des portions d un univers global telles les îles de Second Life, soit des univers parallèles comme les royaumes de World of Warcraft. Cela accroît le nombre maximum de joueurs simultanés potentiels, mais présente un coût élevé et ne permet toujours pas les interactions de joueurs entre différents univers. L architecture C/S simplifie le contrôle contre la triche : tout serveur géré par le fournisseur du jeu peut être considéré comme fiable et servir d arbitre. Un serveur centralisé vérifie chaque commande reçue, cela empêche par exemple qu un joueur modifie sa copie du logiciel afin d introduire des commandes illégales de mouvement. Une telle solution a un impact fort sur la performance du serveur, tout particulièrement sur sa capacité à passer à l échelle en fonction du nombre de joueurs connectés. Il est possible de réduire le coût de cette solution en vérifiant aléatoirement une partie des commandes reçues, mais dans ce cas la détection n est plus totale, certaines triches peuvent par conséquent rester impunies. Il y a par ailleurs des méthodes de triche qu une architecture C/S ne peut pas contrer. Un joueur en passe de perdre peut tenter d annuler une partie en surchargeant le serveur par le biais d un DDoS [11]. Une architecture décentralisée serait plus résistante vis-à-vis de ce type d attaque. Dans une architecture décentralisée, il n est pas facile de sélectionner les nœuds suffisamment fiables pour juger des combats. Déléguer l arbitrage à n importe quel nœud du réseau est particulièrement risqué : un arbitre malhonnête est bien plus dangereux qu un joueur malhonnête. Dans l exemple précédent où un joueur envoie des commandes incorrectes, une approche naïve serait de laisser l arbitrage aux deux nœuds adversaires d un même combat. Cela introduit toutefois une faille : tout nœud malhonnête peut alors refuser des commandes correctes lorsqu elles le désavantagent. Comme il est à la fois difficile et coûteux pour un joueur de contrôler plus d un nœud, la fiabilité d une décision croît donc naturellement avec le nombre de nœuds impliqués. D un autre côté, l implication d un nombre trop important de nœuds pour chaque décision impacte grandement les performances : la latence induite peut être prohibitive. Dans cet article, nous présentons une approche décentralisée qui délègue les décisions d arbitrage aux nœuds joueurs. Nous choisissons les arbitres en fonction de leur fiabilité, évaluée par le biais d un système de réputation. Nous produisons des résultats expérimentaux qui montrent qu un simple vote parmi un petit nombre d arbitres augmente la fiabilité des décisions de manière significative sans pour autant entraver le passage à l échelle du système. Modèle système et modèle de fautes Notre système est basé sur l utilisation d un réseau logique P2P comme [6] ou [4]. Ces réseau logiques induisent nos hypothèses de base. Il n y a pas de limite sur le nombre total de nœuds joueurs. Les états des joueurs sont stockés/répliqués dans les nœuds du réseau et chaque nœud joueur maintient une liste de ses voisins géographiques. La phase de téléchargement du jeu est considérée complète : toutes les données statiques du jeu sont installées sur chaque nœud. Tous les échanges de données sont asynchrones. Les nœuds ne communiquent que par échanges de messages ; ils ne partagent pas de mémoire. Nous voulons que notre approche distribuée puisse au moins égaler le degré de protection d une approche C/S. Pour ce faire notre solution prend en compte toutes les fautes suivantes : introductions de délais ou de modifications dans le protocole de communication, modification du code et/ou des données stockées, attaques DDoS, collusion de deux nœuds. Notre but est d assurer un taux de triche faible même quand ces fautes surviennent. Le système de matchmaking, la partie logicielle du jeu qui met en relation des adversaires pour chaque

3 combat, dépasse le cadre de cet article. La conserver sur un serveur centralisé n aurait que peu d impact sur les performances et nous considérons cette partie comme fiable. Certaines attitudes malhonnêtes, comme le gold farming et le phishing, n introduisent pas d actions illégales dans le jeu. Elles ne sont pas encore détectées ni résolues par les architectures C/S actuelles ; nous ne les traitons pas non plus. Afin de pouvoir passer à l échelle, notre architecture décentralisée a besoin de nœuds fiables pour l arbitrage. Il est risqué de confier un statut d arbitre sans précaution car cela constitue une faille facilement exploitable. C est pourquoi notre solution s appuye sur l utilisation d un système de réputation distribué pour identifier les nœuds les plus dignes de confiance. N importe lequel des systèmes de réputation décrits dans [7] peut faire l affaire, du moment qu il collecte des avis à propos des comportements des nœuds et qu il calcule des valeurs qui vont décrire ces comportements. Pour des raisons d implémentation nous avons intégré notre propre système de réputation à notre approche, mais sa description dépasse le cadre de cet article. 3. Conception d un système d arbitrage décentralisé Le but principal de notre approche est de fournir un service efficace pour la détection décentralisée de triche dans les jeux vidéos. Dans cet article, le cas d étude se porte sur les combats joueur contre joueur, car ce sont les ensembles d actions les plus difficiles à sécuriser. Chaque joueur possède un identifiant unique qui est associé à son nœud réseau, typiquement l ordinateur sur lequel le joueur exécute le logiciel de jeu. Chaque noeud lance le même moteur de jeu, c està-dire le code qui définit le monde, ses règles, et ses protocoles. Un avatar représente un joueur dans le monde virtuel. Les données décrivant le statut dynamique de l avatar constituent l état du joueur ; il est stocké localement sur le noeud du joueur et répliqué sur d autres pairs pour préserver son intégrité. Chaque noeud maintient aussi une liste des voisins dans le monde virtuel, ainsi qu une liste de ses voisins dans le réseau P2P. Le mécanisme de détection de triche est basé sur l utilisation de pairs particuliers appelés arbitres. Pour empêcher les collusions, un joueur ne doit pas avoir la possibilité de choisir un arbitre précis. Dans ce but, notre approche se base sur un système de réputation pour distinguer les nœuds honnêtes des nœuds malhonnêtes. Cela permet de choisir les arbitres parmi les nœuds les plus fiables. Nous déterminons qu un noeud agit honnêtement en fixant une limite T sur sa valeur de réputation. La valeur de T est fortement dépendante de la conception du jeu ; elle résulte d un compromis entre détection de triche et performance. Un nœud ne considérera un autre nœud comme de confiance que si sa valeur de réputation dépasset. Après avoir été sélectionnés dans le réseau P2P, les arbitres vont agir comme des serveurs/super-pairs pour les autres nœuds. N importe quel nœud du réseau peut devenir un arbitre : le critère de sélection est la proportion de requêtes correctement arbitrées. Les ressources qui étaient requises par les serveurs dans le modèle C/S sont ainsi entièrement réparties dans le réseau pair à pair Un protocole générique pour arbitrer les combats La figure 1 dépeint notre approche décentralisée d arbitrage. Une phase d initialisation permet au système de réputation d effectuer une première estimation du comportement de chaque nœud. Ensuite, chaque nœud peut décider d initier un combat avec n importe quel autre nœud et demande à un ou plusieurs arbitres de juger l issue du combat. Un combat entre deux adversaires engendre plusieurs escarmouches jusqu à ce qu une victoire émerge. Pendant un combat, chaque arbitre juge les commandes des joueurs envoyées, et ensuite décide de la suite du combat en fonction des données du jeu et de la validité des commandes reçues. Un problème classique des applications utilisant un système de réputation est le lancement. Comme il n y a eu aucune transaction, il est impossible de déterminer les nœuds fiables. Juger de la fiabilité des nœuds rejoignant l application constitue un problème similaire. Nous résolvons ce problème en injectant de fausses requêtes dans le flux des demandes normales d arbitrage. A la réception d une requête d arbitrage, un nœud ne peut pas déterminer si elle est fausse ou légitime ; il va donc devoir traiter chaque requête comme légitime. Cela accélère la collecte d information de réputation sur les nœuds, et participe à la prévention de la triche en décourageant les comportements malhonnêtes : la falsification étant déjà risquée, elle perd encore de son intérêt si elle n entraîne poten-

4 Initialisation De faux combats sont lances pour tester les arbitres Lancement des combats Selection d ennemis aleatoires pour faire des combats Combats Les noeuds malhonnetes envoient de faux etats ou actions Si les deux noeuds sont honnetes le combat continue Resultats Les noeuds malhonnetes sont punis en baissant leur reputation La reputation des noeuds honnetes est augmentee FIGURE 1 Résumé de notre protocole décentralisé d arbitrage et automate d analyse des arbitres tiellement aucun bénéfice. Au lancement du jeu, toutes les requêtes sont fausses jusqu à ce que le système de réputation puisse délivrer des valeur de réputation fiables. Quand le système de réputation a recueilli suffisamment d évaluations de transactions pour faire émerger des arbitres potentiels, les vrais combats peuvent être traités sous la supervision d un ou plusieurs arbitres. Quand un combat a été initialisé, les nœuds s opposant peuvent créer des événements qu ils enverront aux arbitres. Ces événements sont de deux types : les actions décrivant des actions dans le jeu et les états contenant les états des joueurs. Dans notre modèle, un tricheur est un joueur qui essaye (a) de contrefaire un événement qui ne peut pas correspondre à son état selon le moteur du jeu ou (b) de retarder l émission d un événement. A la réception d un événement émis par un joueur, un arbitre vérifie si l événement est valide avant de le transférer à son adversaire. Les événements sont alors échangés entre les deux adversaires uniquement sous la supervision d un ou plusieurs arbitres, jusqu à un événement validant la fin d un combat, voire une victoire. Si un tricheur tente de se déclarer vainqueur de manière illégale, les arbitres et le joueur ennemi détecteront sa tentative. Afin d optimiser la détection de la triche, notre système choisit les arbitres parmi les plus fiables dans le voisinage physique du nœud joueur. Rappelons que les nœuds fiables sont ceux dont la valeur de réputation a dépassé un seuil fixé. Les nœuds impliqués dans un combat sont exclus de la sélection d arbitres, étant donné que l auto-arbitrage est prohibé pour des raisons évidentes. Comme les valeurs de réputation sont dynamiques, il est possible pour un arbitre de perdre sa légitimité au cours d un combat. Dans ce cas, le combat est annulé : toutes les requêtes d arbitrages seront marquées comme fausses et ne seront utilisées que comme informations pour notre système de réputation Détection de la triche Chaque combat constitue un événement dans lequel chaque nœud peut essayer de corrompre le combat a son avantage. Nous décrivons ici comment le système d arbitrage vérifie les événements. Chaque joueur peut créer des événement basés sur le moteur du jeu. De façon à changer l état de son avatar, un joueur doit émettre une demande d arbitrage contenant la description de l événement. A la réception de deux descriptions associées au même événement un pour chaque combattant, un arbitre va utiliser le moteur du jeu pour vérifier : l état initial et sa cohérence avec les répliques stockées dans le réseau P2P ; chaque action, pour évaluer si elles sont cohérentes avec l état du joueur ; le nouvel état de chaque combattant, pour assurer que toutes les actions ont été appliquées ; des annonces de victoires, pour protéger des tentatives de triche les plus simples. Un combat déclenche une boucle de vérifications chez l arbitre (voir figure 1) ; une vérification par escarmouche jusqu à une victoire, ou jusqu à ce que le combat soit annulé. Les arbitres d un même combat envoient leurs décisions aux joueurs directement ; ils ne communiquent pas pour atteindre un consensus. Cela n introduit pas de brèche dans notre sécurité, car notre architecture détecte systématiquement les tentatives de triche, qu elles viennent d un joueur ou d un arbitre. Si l un des arbitres envoie une décision falsifiée aux joueurs, ces derniers vont la détecter. Si un joueur mal-

5 honnête décide de prendre en compte une décision falsifiée, les arbitres honnêtes vont détecter l état de ce joueur comme incorrect à la prochaine itération. Enfin, si une décision falsifiée donne un nœud malhonnête comme vainqueur, et si le nœud malhonnête omet d envoyer un message annonçant sa victoire, son adversaire et les arbitres le considéreront à terme comme malhonnête Multiplier les arbitres pour améliorer la détection de la triche Un arbitre unique n est pas un gage fiable de résistance à la triche. Un nœud malhonnête peut temporairement envoyer des réponses correctes, et ensuite émettre des décisions corrompues si il arrive à acquérir un statut d arbitre fiable. L association de plusieurs arbitres à chaque combat entrave ce genre de comportement. Le premier avantage de cette approche est qu elle améliore la détection des arbitres malhonnêtes. La probabilité de sélectionner N arbitres malhonnêtes pour un même combat est considérablement plus faible que celle d en sélectionner un seul. Le second avantage est l impact sur les collusions entre joueurs et arbitres. La collusion est une stratégie coûteuse, et le coût croit exponentiellement avec le nombre de nœuds impliqués. Cela est encore plus vrai dans notre approche car : un joueur ne peut pas influencer la sélection des arbitres, les nœuds travaillant en collusion doivent d abord obtenir de bonnes réputations avant de commencer à tricher, un nœud ne peut jamais savoir si la requête d arbitrage qu il traite est fausse ou non. Nous avons analysé l impact du nombre d arbitres sur l efficacité de la détection de la triche et sur le surcoût. Les résultats de cette analyse, parmi d autres résultats, sont présentés en section Évaluation de performances Dans cet article nous visons à offrir un système d arbitrage alternatif à l architecture C/S dans le contexte des MMOGs. Le surcoût généré par notre solution doit être minimisé pour permettre le passage à l échelle et pour offrir une expérience utilisateur indiscernable de celle des jeux en C/S. Afin de permettre la comparaison de notre approche avec l approche client/serveur, nous définissons un serveur comme un nœud aux capacités matérielles illimitées, pouvant gérer l ensemble des autres nœuds du réseau Configuration et paramètres de la simulation Nos simulations sont basées sur le moteur de simulation à événements discrets de PeerSim [10]. Pour tester nos critères de performance nous avons mesuré une moyenne sur 40 simulations avec un temps simulé de24 heures chacune. Nos métriques sont : le pourcentage de triche non détectée sur l ensemble des tentatives de triche, la consommation de bande passante, la latence introduite par notre protocole. La taille de notre réseau est fixée à la plus grande valeur que notre simulateur pouvait gérer sur nos machines de tests :30000 nœuds. Cette valeur est supérieure à l habituelle limite du modèle client/serveur qui empêche les compagnies de jeux de créer des univers avec plus de joueurs pour une qualité de service acceptable. Nous avons également lancé des courtes simulations jusqu à nœuds qui ont montré le même comportement que celles à Notre approche semble se comporter de manière presque indépendante du nombre de nœuds dans le réseau. La latence est choisie de manière aléatoire entre10 et40 ms pour chaque message. Cette plage de valeurs est issue d une série de mesures sur 11 serveurs du jeu Guild Wars 2 choisis au hasard. Le surcoût induit par notre solution sera calculé en comptabilisant le délai additionnel par rapport aux messages de jeu envoyés à un serveur. La consommation de la bande passante est calculée pour chaque message envoyé dans notre simulation. Il est facile de comptabiliser le nombre de messages envoyés, et le nombre de ceux envoyés avec un contenu particulier. Nous pouvons alors mettre en relation le contenu des messages avec des réels usages mémoire comme des entiers, ou des flottants pour calculer des tailles de messages réalistes.

6 La charge CPU. Nous donnons un "point de charge CPU" à chaque création d action/état (utilisation CPU liée au jeu) et à chaque test d action/état (utilisation CPU liée à notre approche). Notez que cette méthode surestime notre surcoût CPU. Dans une implémentation réelle le coût des tests est bien inférieur à celui d autres opérations à forte consommation CPU, comme les calculs Nvidia PhysX. Taux de triche toléré.a notre connaissance, il n existe pas d étude sur les taux de triche non détectée dans les jeux en ligne. Notre but est de minimiser cette valeur, tout en préservant la capacité à passer à l échelle et les performances réseau Proportion de nœuds malhonnêtes et taux de détection Nous simulons plusieurs comportements de triche. Une personne utilisant le service peut vouloir tricher en tant que joueur, mais ne veut pas forcément déranger les autres joueurs. Il est aussi possible qu à l opposé cette personne prenne plaisir à endommager le système sans y jouer. C est pour cela que nous dissocions les deux mesures. Dans les publications ayant trait aux comportements malhonnêtes en P2P, il est communément estimé que 5% de nœuds malhonnêtes est une valeur haute. En considérant que la triche pourrait être plus répandue dans les jeux en ligne, nous avons fixé cette proportion à 30% pour les joueurs, et à 10% pour les arbitres. La proportion plus faible d arbitres malhonnêtes est un choix de notre part. Nos simulations montrent que le nombre de combats possibles décroît quand la proportion d arbitres malhonnêtes croît. Ce résultat nous semble très positif : il signifie que les arbitres malhonnêtes sont bien détectés et évités. Cependant, une trop forte proportion empêche les combats de se dérouler puisque les tentatives de triche vont conduire à des annulations. En revanche, lorsque nous faisons varier la proportion de joueurs malhonnêtes entre 0% et 45% cela n affecte pas la proportion de triche non détectée, qui ne dépasse jamais 0,013%. Nous avons donc gardé10% d arbitres malhonnêtes, qui reste une valeur très haute. Nous avons également testé les limites de notre solution : au-delà de 45% d arbitres malhonnêtes et 30% de joueurs malhonnêtes, le système trouve difficilement un ensemble d arbitres et deux joueurs honnêtes pour commencer et finir un combat. Il devient alors impossible de finir une simulation avec des résultats valables Coûts induits par notre solution Surcoût CPU. Le surcoût CPU est lié au nombre d arbitres que nous utilisons. Il est apparu que, même en optimisant nos tests, l approche utilisant 5 arbitres présente un surcoût trop important pour être utilisée. Si les jeux actuels utilisent en moyenne deux cœurs CPU, nous pouvons considérer qu un processeur quad-core peut supporter un surcoût maximum de100%. Nous calculons les valeurs de surcoût CPU comparées avec la valeur de surcoût CPU qui serait nécessaire pour ne laisser que 1% de triche non détectée. En faisant ainsi, nous obtenons que la solution la plus efficace en terme d utilisation CPU est l approche avec 3 arbitres : elle offre un rapport de 0, 0128%. Les deux autres solutions sont quant à elles moins performantes : 32, 6625% pour la mono-arbitre et 2,10% pour la penta-arbitres. Ces résultats montrent à quel point notre approche "multi-arbitres" est efficace en terme d utilisation CPU lorsqu on la compare au mono-arbitre. Surcoût latence. Nous avons d abord vérifié si notre protocole n ajoute pas trop de latence sur le jeu lui-même. Nous avons donc relevé les surcoûts en latence de chaque message. Nos résultats montrent que nous ajoutons une latence comparable à celle d un échange de messages entre les nœuds de notre réseau : 40ms. Cela provient de la communication en deux phases entre les pairs et les arbitres. Un message n a plus besoin d aller au serveur, mais doit passer par un pair dont la latence est plus grande que celle d un serveur centralisé. Même si nous considérons une forte latence de 100ms, la latence totale de 200ms reste acceptable pour un environnement de jeu. Surcoût bande passante. Comme le montrent les figures 2a, notre solution utilise en moyenne 4ko/s une fois l évaluation des réputations stabilisée, et ce quel que soit le nombre de nœuds joueurs. Ce résultat est à comparer aux 40Mo/s qui auraient été nécessaires à un serveur centralisé pour gérer nœuds. Le pic de débit en architecture C/S monte à 67Mo/s ce qui est, en réalité, impossible à gérer pour un seul ordinateur. Dans un jeu actuel, le serveur serait tombé et les joueurs auraient été déconnectés. Ce type de défaillance est fréquent dans les jeux actuels.

7 Bande passante d'un noeud en ko/s Bande passante du serveur en ko/s Temps de simulation (en heures) Temps de simulation (en heures) (a) Comparaison de la bande passante utilisée entre noeud du réseau et serveur centralisé Pourcentage de bande passante consommee Temps de simulation (en heures) (b) Consommation du système de réputation FIGURE 2 Résultats concernant la bande passante Notre approche est basée sur un système de réputation, dont le classement permet de trouver les nœuds de confiance. Le coût d une telle solution reste faible : nous avons analysé combien de bande passante notre mécanisme de réputation consommait sur les 4ko/s. La figure 2b montre que nous utilisons à peine1,5% de toutes les données envoyées. 5. Travaux connexes Des surcouches P2P répondant aux besoins des jeux vidéos ont déjà été proposées. Colyseus [2], Blue- Banana [8], et Solipsis [4] visent à adapter les positions des nœuds dans le réseau pour les besoins des applications ; cela les rend compatibles avec des MMOGs. Colyseus est suffisamment efficace pour servir d infrastructure à des jeux FPS. Les MMORPGs (jeux de rôle) ont des taux de rafraîchissement plus bas et sont beaucoup moins gourmands en bande passante que les jeux FPS [3]. Dans ce contexte, Bluebanana et Solipsis adaptent leur topologie à la mobilité des avatars. Cependant aucune de ces approches ne s attaque au problème de la triche. Pour détecter la triche de manière distribuée, [6] et [12] collectent toutes les informations nécessaires à une architecture décentralisée et fiable pour MMOGs, et introduisent le concept d arbitrage décentralisé dans le réseau P2P en implantant des entités de confiance. Comme chaque action dans un jeu peut être discrétisée en événements atomiques, l analyse et l arbitrage des actions d un jeu sont déléguées à ces entités. Ces solutions introduisent les bases pour le jeu pair à pair décentralisé. Cependant elles ne tolèrent pas un grand nombre de nœuds malhonnêtes. Notre approche est similaire à RACS [12], qui toutefois ne gère ni la sélection des entités de confiance ni la coopération entre arbitres. Un autre type d approche [5] mélange les bénéfices d un équilibrage de charge P2P avec un serveur centralisé. Une telle approche hybride nécessite également d identifier des nœuds de confiance dans le réseau pour déléguer les tâches d arbitrage. Bien que cela aide le serveur à gérer un grand nombre d opérations dépendantes du CPU, le nombre maximum de joueurs connectés simultanément reste limité en-deçà des besoins d un MMOG actuel.

8 Notre solution peut utiliser n importe quel système de réputation décentralisé qui identifie les arbitres potentiels. Elle ne repose ni sur des contrôleurs de régions du réseau, ni sur des nœuds choisis de la surcouche P2P. De plus notre approche permet de déléguer chaque arbitrage à un ensemble de nœuds faisant office de jury. Comme le montrent nos simulations, notre approche résiste à la triche de manière efficace et permet de passer à l échelle. 6. Conclusion et travaux futurs Les architectures totalement pair à pair permettent le passage à l échelle des MMOGs. Cependant elles font face à un problème majeur : il est difficile de contrôler le respect des règles d un jeu dans une architecture entièrement décentralisée. Nous proposons une solution P2P basée sur un système de réputation, qui identifie efficacement les nœuds de confiance parmi les joueurs et les fait coopérer sur l arbitrage du jeu. L évaluation de notre approche montre qu il est possible de fournir un système pour MMOG gérant efficacement la triche et passant à l échelle. Nous avons réduit à 0,0128% la proportion de triche non détectée en dépit d une concentration importante de nœuds malhonnêtes (40%). Pour approfondir la validation de notre approche, notre objectif à court terme est de développer un prototype réaliste et de le déployer sur Grid5000 pour effectuer des tests d échelle. Nous prévoyons également d étendre notre approche à d autres types de triche, par exemple les modifications du moteur physique du jeu. Enfin nous travaillons actuellement à une optimisation probabiliste de notre solution, dans laquelle les nœuds ayant acquis une très bonne réputation ne sont pas testés systématiquement. Bibliographie 1. Blizzard admits diablo 3 item duping is why asia s server was shutdown, June http :// Was-Shutdown html. 2. Bharambe (A.), Pang (J.) et Seshan (S.). Colyseus : a distributed architecture for online multiplayer games. In : Proceedings of the 3rd conference on Networked Systems Design & Implementation - Volume 3. pp Berkeley, CA, USA, Chen (K.-T.), Huang (P.), Huang (C.-Y.) et Lei (C.-L.). Game traffic analysis : an mmorpg perspective. In : Proceedings of the international workshop on Network and operating systems support for digital audio and video. pp New York, NY, USA, Frey (D.), Royan (J.), Piegay (R.), Kermarrec (A.-M.), Anceaume (E.) et Le Fessant (F.). Solipsis : A Decentralized Architecture for Virtual Environments. In : 1st International Workshop on Massively Multiuser Virtual Environments. Reno, NV, États-Unis, Goodman (J.) et Verbrugge (C.). A peer auditing scheme for cheat elimination in mmogs. In : Proceedings of the 7th ACM SIGCOMM Workshop on Network and System Support for Games. pp New York, NY, USA, Hampel (T.), Bopp (T.) et Hinn (R.). A peer-to-peer architecture for massive multiplayer online games. In : Proceedings of 5th ACM SIGCOMM workshop on Network and system support for games. New York, NY, USA, Jøsang (A.), Ismail (R.) et Boyd (C.). A survey of trust and reputation systems for online service provision. Decision Support Systems, vol. 43, n2, mars 2007, pp Legtchenko (S.), Monnet (S.) et Thomas (G.). Blue Banana : resilience to avatar mobility in distributed MMOGs. Rapport de recherche nrr-7149, INRIA, Miller (J.) et Crowcroft (J.). The near-term feasibility of P2P MMOG s. In : Network and Systems Support for Games (NetGames), th Annual Workshop on, pp Montresor (A.) et Jelasity (M.). PeerSim : A scalable P2P simulator. In : Proc. of the 9th Int. Conference on Peer-to-Peer (P2P 09), pp Seattle, WA, sep Specht (S. M.) et Lee (R. B.). Distributed denial of service : taxonomies of attacks, tools and countermeasures. In : Proc. of the Int. Workshop on Security in Parallel and Distributed Systems, pp Webb (S. D.), Soh (S.) et Lau (W.). RACS : A Referee Anti-Cheat Scheme for P2P Gaming. In : Proc. of the Int. Conference on Network and Operating System Support for Digital Audio and Video (NOSS- DAV 07).