Ecole d'ingénieur et centre de recherche en télécommunications
Giuseppe REINA
|
Giuseppe REINA
Eurecom - Réseaux et Sécurité
Doctorant
04 93 00 82 49
04 93 00 82 00
371
|
Thèse
Architecture pair à pair pour applications interactives sur InternetResponsable(s)
Les tous premiers jeux en réseaux étaient limités aux réseaux locaux et seuls quelques joueurs pouvaient interagir entre eux. Ensuite, les jeux se sont ouverts à Internet, offrant la possibilité d’échanger avec des personnes à l’autre bout du monde. Pour autant, le nombre de joueurs restait assez limité. Les jeux en ligne étaient alors peu répandus.
Aujourd’hui, ces jeux en ligne sont devenus très populaires. Plusieurs millions d’utilisateurs jouent ensemble sur Internet. « World of Warcraft » est un bon exemple de jeux en-ligne à grand succès: plus de 6.000.000 de joueurs payent chaque mois un abonnement. 500.000 joueurs sont connectés à tout moment. Les prévisions concernant ces jeux sont exponentielles. De plus, les mondes virtuels partagés tels que Second Life, permettent a des milliers de joueurs de communiquer dans le cadre d’un monde virtuel. Ces différentes applications ont des contraintes et propriétés très différentes qui requièrent des architectures spécifiques.
Créer des applications temps-réel interactives réussissant à supporter un tel nombre d’utilisateurs tout en s’assurant que les joueurs aient une qualité de jeux acceptable et une bonne interactivité demeure une tâche complexe.
Pour un joueur le critère de qualité est le délai, c’est- à -dire le temps de réponse minimal pour que les actions des joueurs soient prises en compte dans le jeu. Le temps de réaction des êtres humains varie entre 150ms à 180ms. Au-dessus de ce seuil, le joueur ressentira une dégradation de la qualité du jeu. De plus, cela induira une inégalité entre les joueurs ayant des délais court et ceux ayant des délais plus longs. A ce propos, plusieurs études montrent que le niveau de satisfaction des utilisateurs est directement lié et proportionnel au temps de réponse du jeu. Les mondes sociaux virtuels sont plus tolérants aux délais, mais la création fréquente d’objets par les participants et le grand nombre de participants se réunissant autour d’événements sociaux rend difficile de maintenir une vision consistante du monde pour tous les joueurs. Maintenir la consistance des données reçues par les joueurs consiste à assurer que tous les joueurs voient le même jeu ou monde.
La bonne gestion des délais devient d’autant plus difficile que des joueurs malhonnêtes participent aux jeux. Ces joueurs vont essayer de tricher pour modifier la partie à leur avantage. Plus généralement la tricherie consiste à changer le comportement du jeu à l’avantage d’un ou plusieurs joueurs.
D’un point de vue plus technique, l’état actuel de la technologie pour les jeux en-ligne consiste à utiliser une architecture client-serveur. Ce type de solution est assez simple et permet une gestion simplifiée de la relation joueurs/jeux. Chaque joueur doit absolument passer par le serveur central afin de communiquer avec les autres pairs.
Ce type d’architecture présente de nombreux avantages et permet assez facilement de contrôler le jeu : des tâches comme la facturation, la gestion des droits d’accès au jeu, la gestion de la consistance de l’état du jeu chez chaque joueur, ainsi que la synchronisation et la gestion des délais peuvent être gérés par le serveur central. Ce serveur central peut également être utilisé pour détecter ou éviter toute forme de tricherie. En revanche, cette solution présente également quelques inconvénients :
- Les(s) serveur(s) doit (vent) être physiquement déployé(s) et maintenu(s).
- Les systèmes centralisés ne passent pas à l’échelle. Cela suppose que les serveurs soient dimensionnés selon le nombre de joueurs acceptés. Ainsi, il est nécessaire de surdimensionner les serveurs au risque de gâcher de la ressource.
- Le serveur centralisé est un point unique de rupture.
- Etant donné le nombre croissant d’utilisateurs dans le monde, il devient difficile de décider de la localisation du serveur de manière à ce que le temps de réponse soit équivalent pour tous les utilisateurs dans le monde.
Tous ces inconvénients ainsi que les coûts engendrés par une solution centralisée, imposent d’étudier des cas d’architectures alternatives pour les jeux en-ligne.
L’avenir de la communication sur Internet réside dans le pair-à-pair. La conception d’une architecture pair-à-pair pour les applications interactives sur Internet est un challenge difficile. Ainsi nous proposons de remplacer le serveur central par une architecture distribuée qui s’appuie sur les ressources des joueurs (PC, console de jeu, set-top-box, tripleplay gateway). Le but de ce remplacement serait de permettre une communication directe entre pairs au lieu d’obliger chaque pair à passer par le serveur central. Les bénéfices d’une architecture pair-à-pair seraient les suivants :
- pas d’investissement supplémentaire pour déployer le jeu.
- Une telle architecture passe à l’échelle. Chaque pair met à disposition ses ressources quand il utilise le système.
- le point de rupture n’est plus unique. Le départ (volontaire ou non) ou l’arrivée d’un nouveau joueur n’affecte pas la continuité du service. L’architecture pair-à-pair est robuste par définition.
- Enfin, cette architecture s’organise de manière à optimiser les délais entre les pairs. Comme évoqué ci-dessus, le délai est le meilleur indicateur de satisfaction chez les joueurs.
Néanmoins, le pair-à-pair présente aussi ses inconvénients. Son architecture distribuée en fait un système très complexe. Les tâches les plus difficiles se retrouvent dans : le contrôle d’accès au jeu, la lutte contre la tricherie, la synchronisation entre joueurs ainsi que la maintenance de l’état du jeu et des joueurs. Par conséquent, l’architecture pair-à-pair regroupe ainsi de nombreux sujets de recherches passionnants que nous nous proposons d’étudier.
Pour cette étude, nous allons recenser les architectures pair-à-pair qui prenne en compte les dynamiques et les interactions d’un jeu en ligne ou d’un monde social virtuel. Le jeu défini le type d’interactions qui nous aidera ensuite à choisir la façon la plus adéquate de construire et de gerer le réseau pair-à-pair. Nous étudierons et évaluerons les réseaux structurés (Distributed Hash Tables) et les réseaux non-structurés tels que Gnutella ou BitTorrent. De plus, nous essayerons de trouver de nouveaux mécanismes en fonction des contraintes de l’application (plus interactive, avec peu de création d’objets, ou peu interactive avec beaucoup de mouvement et de création d’objets. On divisera le monde virtuel en régions, chacune de ces régions étant gérée par un réseau pair-à-pair. Nous pouvons également imaginer prendre en compte les interactions les plus récentes des joueurs, ainsi que les objets pour construire ce réseau.
La consistance des informations est un problème supplémentaire. Nous devons nous assurer de la véracité des données que chaque joueur reçoit ainsi que de la bonne chronologie des actions exécutées par les autres joueurs. Pour autant, dans un monde virtuel, un joueur n’est intéressé que par les informations avec lesquelles il est en train d’interagir. Aussi, pour chaque joueur, est-il possible de restreindre la condition de consistance des états à des régions plus spécifiques (connues sous le nom de regions d’interet).
Comme nous pouvons le constater, ce sujet est très riche et présente de nombreuses approches différentes. Ces éléments nous laissent penser qu’il est intéressant de créer un modèle de jeu en-ligne qui repose sur une architecture complètement distribuée; le but de cette thèse sera d’étudier les performances, les faiblesses et les forces des architectures proposées et de concevoir et implémenter une nouvelle architecture flexible et adaptables aux différentes contraintes de la gamme d’application interactives sur Internet. Notre architecture sera conçue pour fonctionner sur des ressources limitées tel que l’on peut trouver a la maison (PC portable, Set top Box).
Un autre challenge important est la lutte contre la tricherie dans une architecture pair-à-pair. Voici quelques questions auxquelles nous nous efforcerons de répondre: comment éviter que des joueurs ne distribuent des informations falsifiées sans l’utilisation d’un serveur de confiance ? Comment éviter que des joueurs n’accèdent à des informations dont ils ne sont pas destinataires ? Comment éviter qu’un joueur prétende ne pas avoir reçu d’informations afin d’éviter une issue négative pour lui ? Comment éviter qu’un joueur ne retarde d’autres joueurs ?
Nous envisagerons deux manières de contrer la tricherie :
1) une méthode active, qui rend la tricherie impossible dès le démarrage du jeu.
2) Une méthode réactive, qui détecte la tricherie et prend les mesures adéquates (par exemple en punissant le tricheur ou en le renvoyant du jeu)
L’étude de la tricherie devra s’intégrer au modèle de jeu en-ligne développé auparavant.
Apres une analyse théorique, nous prévoyons d’implémenter cette solution pour pouvoir en étudier les comportements.
- Calendrier des travaux -
T0 à T0+6: définition du problème, étude bibliographique, identification des différentes architectures proposées dans la littérature
T0+6 à T0+12: modification d’un moteur de jeu client/serveur pour supporter le développement d’une architecture pair-à-pair
T0+12 à T0+18: ajout de mécanismes de contrôle de la consistance sur l’architecture précédente, ainsi que de protocoles de communication pair-à-pair structures (DHT) et non structures (Delaunay)
T0+18 à T0+30: expérimentation, évaluation, mesures et amélioration de l'implémentation
T0+30 à T0+36: Finalisation et rédaction de la thèse.
