Les abstractions de communication dans les jeux en réseaux mobiles

Rapport du stage de fin d’´etudes Les Abstractions de Communication dans les Jeux en R´eseaux Mobiles R´ealis´ par LE Van Tuan Promotion 8, IFI Encadrant Antoine BEUGNARD D´epartement Informatique Ecole National Sup´erieur des T´el´ecommunications de Bretagne France, Oct 2004 Remerciements Je tiens `a remercier particuli`erement Monsieur Michel SIMATIC, responsable du projet MEGA, de m’avoir accueilli au sein de son ´equipe Je tiens `a remercier sinc`erement Monsieur Charles DURAND, directeur de l’IFI, de m’avoir aid´e `a pr´eparer le stage Je tiens `a exprimer toute ma sinc`ere reconnaissance `a Monsieur Antoine BEUGNARD, enseignant-chercheur au D´epartement Informatique, Ecole National Sup´erieur de T´el´-communication de Bretagne, de m’avoir bien encadr´ pendant toute la dur´ee de mon stage Je remercie vivement tous les personnels de l’IFI, qui m’ont aid´e pendant mon cursus d’´etudes Finalement, un grand merci `a tous les personnels du D´epartement Informatique de l’ENST Bretagne, `a toutes les membres du projet MEGA, notamment aux stagiaires au laboratoire informatique, ENST Bretagne, qui m’ont port´e leur amiti´e Resum´e´ Notre travail est men´ dans le cadre du projet de recherche MEGA (Mobile MultiPlayEr Game Architecture) qui a pour but de r´ealiser une infrastructure visant aux d ´e-veloppeurs des jeux massivement multijoueurs, particuli`erement dans les environnements mobiles Dans les jeux massivement multijoueurs, plus la communication entre les joueurs est efficace, plus de joueurs peuvent participer au jeu Ainsi, la communication est un des points cruciaux pour le succ`es d’un jeu L’impl´ementation du mod`ele de communication Client/Serveur a montr´e les limitations pour les jeux en ligne, et plus sp´ecialement dans le contexte mobile Le syst`eme Publish/Subscribe augmente le d´ecoupage d’espace d’interaction entre les participants, ainsi facilite la reconfiguration et l’´evolution du syst`eme Il est donc consid´er´ comme une architecture d’intergiciel valable pour les applications fonctionnant en se basant sur les ev´enements (c’est le cas de jeu multijoueur) Il existe dans la litt´erature des impl´ementations du Publish/Subscribe pour les jeux multijoueurs, mais restant dans les syst`emes statiques plutˆot que mobile Nous proposons donc d’utiliser ce mod`ele de communication pour les jeux multijoueurs en r´eseau mobile Dans ce rapport, nous pr´esentons le processus de r´eification d’abstractions de commu-nication du mod`ele Publish/Subscribe Nous proposons ´egalement deux choix de concep-tion du syst`eme sous forme d’un m´edium D’autre part, un algorithme pour le support de l’itin´erance sp´ecifique a` la conception distribu´ee est discut´e Mots-cl´es : Abstractions de communication, architecture et composant, support de la mobilit´e dans Publish/Subscribe , jeux multijoueurs, service de notification Abstract Our work is undertaken within the framework of the research project MEGA (Mobile MultiplayEr Game Architecture), of which the purpose is to build a middleware aiming to the developers of the game multiplayer, particularly in the mobile environments In the game multiplayer, more the communication between the players is e ffective ; more the players can take part in the play Therefore, the communication is one of the crucial points for the success of the game The implementation of the model communi-cation Client/Server showed the limitations for the online game, and more specially in the mobile context The Publish/Subscribe system increases cutting space of interaction between the participants, hence facilitates the reconfiguration and the evolution of the system It is thus regarded as a valuable middleware architecture for the event-driven applications (it is the case of the multiplayer game) In the literature, there exist im-plementations of Publish/Subscribe for the game multiplayer, but remains in the static systems rather than mobile We thus propose to use this model of communication for the game multiplayer in mobile network In this report, we present a process of reification of communication abstractions of the model Publish/Subscribe We also propose two choices of systems design in the form of a medium In addition, an algorithm for the support of the roaming specific to the distributed design is discussed Keywords : Abstractions of Communication, Structures and Composing, Support of Mobility in Publish/Subscribe, Game Multiplayer, Service of Notification Table des matieres` Introduction 1.1 1.2 1.3 1.4 Contexte du stage L’objectif du stage Le M´edium et le processus de r´eification d Organisation du document ´ Etat de l’Art 2.1 2.2 Les types des jeux en ligne Architecture 2.2.1 2.2.2 2.3 Verrous techniques 2.3.1 2.3.2 2.4 Les plates-formes existantes 2.4.1 2.4.2 2.4.3 Conclusion 2.5 Environnements mobiles et Mod`ele de Communication 3.1 Infrastructure Mobile TABLE DES MATIERES 3.2 3.1.1 3.1.2 3.1.3 3.1.4 Le mod`ele Publish/Subscribe 3.2.1 3.2.2 3.2.3 3.3 Sp´ecification abstrait du m´edium PublishSubscribeMedium 3.3.1 3.3.2 3.3.3 3.4 Conclusion Processus de raffinement 4.1 4.2 Premi`ere ´etape : introduction des gestion Deuxi`eme ´etape : Choix de conception 4.2.1 4.2.2 Conclusion Annexe : Sp´ecification OCL des services apr`es la premi`ere ´etape Annexe : Sp´ecification OCL des services du m´edium, version centralis´ee Annexe : Discussion suppl´ementaire sur la table de routage Bibliographie 66 Table des figures 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 Topologies de r´eseaux 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 Mod`ele de calcul mobile 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 Introduction des gestionnaires sur le diagramme de collaboration L’effet de la latence L’ex´ecution du remorquage d’´etat de synchronisation dans TSS (Quak L’architecture en couche de Continuum Les composants dans un jeu construit sur TerraPlay Une architecture typique d’un jeu sur TerraPlay La communication dans syst`eme TerraPlay Architecture de ButterFly Mod`ele Publish/Subscribe de base d´ecoupage de l’espace d’interaction dans un syst`eme Publish/Subscri d´ecoupage d’´ecoulement d´ecoupage de temps Architecture hi´erachique Architecture pair-a`-paire acyclique et pair-a`-pair g´en´erale Architecture hybride Diagramme de collaboration du m´edium Publish/Subscribe Vue dynamique du m´edium Publish/Subscribe Vue dynamique apr`es l’introduction des gestionnaires Premi`ere choix de conception : gestion centralis´ee Vue dynamique de version centralis´ee : le cas de service subscribe Vue dynamique de version centralis´ee : le cas de service publish La relation entre des cuortiers dans la topologie hi´erachique et pair-a`-p La construction de la table de routage en pair-a`-pair acyclique La construction de la table de routage en hi´erachique Second choix de conception : gestion distribu´ee Vue dynamique de la version distribu´ee, le cas de message subscribe Chapitre Introduction 1.1 Contexte du stage Aujourd’hui les dispositifs mobiles et sans fils sont omnipr´esents, avec de nombreuses applications Il apparaˆıt rapidement et clairement que le divertissement sera une de ces applications majeures des futurs r´eseaux mobiles N´eanmoins, la plupart des jeux actuellement offerts sur mobiles sont des jeux monojoueurs Pour les jeux multijoueurs, il en existe sur internet de nombreux exemples, mais ils restent limit´es en nombre de joueurs (tout au plus quelques centaines)[46] Ici, nous nous int´eressons au domaine des jeux sur mobile et massivement multijoueurs (plusieurs milliers voire dizaines de milliers de joueurs) Afin de r´eduire le travail de d´eveloppement des jeux multijoueurs, on voudrait ˆetre capable de sp´ecifier et r´ealiser une infrastructure logicielle (un intergiciel), g´erant les probl`emes concernant les communications r´eseaux, ainsi que les gestion des donn´ees, ou bien le passage a` l’´echelle, etc Pour permettre aux d´eveloppeurs de jeux de ne pas s’´ecarter de leur m´etier de base (le jeu) Le projet Mega (commun a` CEDRIC-CNAM , l’ENST, l’ENST Bretagne, et France T´el´ecom R&D, l’INT et l’UBS) a pour objectif de d´efinir une telle infrastructure Ce projet vient de d´ebuter, un ´etat de l’art de l’o ffre des intergiciels existants (Butterfly, Continuum, Terraplay, etc.) est donc n´ecessaire, l’id´eal ´etant de s’appuyer sur une norme des notions offertes (inexistante actuellement) [45] 1.2 L’objectif du stage Le travail sera, dans un premier temps, la r´ealisation d’un ´etat de l’art sur la commu-nication des plateformes intergiciels existantes Le stage qui s’en suivra devra mettre en ´evidence et sp´ecifier des abstractions de communications n´ecessaires dans ce type d’application Les sp´ecifications feront apparaˆıtre des parties fonctionnelles qu’on d´ecrira le plus pr´ecis´ement possible (causalit´e, equit´e, etc.) et non fonctionnelles (robustesse, e fficacit´, etc.) CHAPITRE INTRODUCTION 1.3 Le Medium´ et le processus de reification´ d’Abstractions de Communication Dans un syst`eme distribu´e, les composants ´echangent, ou partagent les informations n ´ecessaires `a l’aide de composants de communication Afin de diff´erencier des autres composants du syst`eme (les composants m´etiers, ou les composants fonctionnels, etc.), Antoine Beugnard et Eric Cariou [20] appellent ces composants de communication des m ´ediums, dont la d´efinition est : (( Un m´edium est une composant logiciel de communication ou d’interaction qui r´eifie une abstraction de communication )) Un m´edium peut impl´ementer une abstraction de communication, un protocole consensus par exemple Dans la suite du stage, nous allons (( r´eifier )) des abstractions de communication dans les jeux en r ´eseau mobile selon le processus ´egalement propos´e par A Beugnard et E Cariou[21] Ce processus consiste `a transformer des abstractions de communication, `a partir de niveau conception le plus abstrait, sous forme de composants logiciels Quelque soit le niveau de manipulation, il permet de r´eserver l’unit´e et la coh´erence d’une abstraction d’interaction pendant tout le cycle de d´eveloppement d’une application Le premier pas de ce processus est de d´eterminer les services que ce composant met-tra `a disposition des autres composants ; et aussi les services requis par le m ´edium pour fonctionner C’est ainsi que la fa¸con dont les entit´es logicielles communiquent est abs-traite de sorte que (( les d´etails sont cach´es )) et non pas (( la notion est floue et mal d´efinie ))[21] Dans ce pas, le m´edium est vu comme un unique entit´ qui fait partie du syst`eme Le processus de ffinement suivant consiste `a transformer cette sp´ecification abs-traite `a plusieurs variantes d’impl´ementation en fonction du contexte d’utilisation, `a tous les niveaux du cycle de vie du logiciel, en continuellement respectant le contrat d’usage du m´edium d´etermin´ lors du niveau le plus abstrait Il s’agit l`a du contrat de la r´ealisation en terminologie de UML Component Voici trois ´etapes du processus de r´eification des abtractions : – Introduction des gestionnaires de rˆole : la premi`ere ´etape du processus de raffinement a pour but de faire apparaˆıtre les types de gestionnaires de rˆole qui forment le m´edium lors de d´eploiement – Choix de conception : le r´esultat de cette ´etape est une sp´ecification d’impl ´ementa-tion – Choix de d´eploiement : il s’agit de d´efinir l’architecture de d´eploiement des gestion-naires du m´edium A chaque ´etape de ce processus, des diagrammes de collaboration UML sont utilis´es pour d´ecrire l’aspect structurel du m´edium, mettre en ´evidence la s´emantique et le comportement dynamique de chacun des services du m´edium au niveau sp´ecification Dans la derni`ere ´etape, le diagramme de d´eploiement est employ´ pour chaque type de d´eploiement d´efini Outre, des contraintes OCL, des diagrammes d’´etats sont utilis´es en plus La r´eification est l’op´eration de transformation en quelque chose de concret CHAPITRE INTRODUCTION pour une sp´ecification plus claire du m´edium Dans le cardre du stage, nous ne r ´ealiserons que deux premiers ´etapes 1.4 Organisation du document L’´etat de l’art dans le chapitre donne une vue g´en´erale sur la situation actuelle des jeux multijoueurs Les verrous techniques rencontr´es pour pouvoir mettre en ouevre un jeu massivement multijoueurs sont ´egalement discut´es dans ce chapitre A partir de cette discusion, nous sommes arriv´es a` choisir le mod`ele de communication Publish/Subscribe Selon notre avis, c’est celui qui est le plus convenable pour les jeux multijoueurs dans le contexte mobile Ce mod`ele de communication, avec une sp ´ecification abstraite est d´ecrit dans le chapitre Ensuite, le processus de (( r ´eification )) des abstractions de communication du Publish/Subscribe s’est retrouv´ dans chapitre Le dernier chapitre est une conclusion du document Fig 4.10 – Vue dynamique de la version distribu´ee, le cas de message subscribe 4.2.2.3 Specification´ OCL On s’int´eresse tout d’abord aux sp´ecifications de la classe SubscriberManager L’ap-parition de la classe IBorderBroker sur le diagramme am`ene les changements par rapport a` la sp´ecification faites pr´ec´edemment Ces sp´ecifications sont les suivants : On peut noter qu’un appel sur l’op´eration register() sur un courtier fronti`ere est ajout´e dans la post-condition de cette op´eration En effet, dans toutes les op´erations impl´ement´ees par les gestionnaires, ceux-ci ne font que transf´erer tous les appels des clients au syst`eme ; et m ´emorisent ´eventuellement quelques informations suppl´ementaires Les changements dans les op´erations unsubscribe() et pull() sont presque identiques De mˆeme que pour le cas pr´ec´edent des gestionnaires des subscribers, les gestionnaires des publishers re¸coivent les appels des services de ses clients, ensuite simplement CHAPITRE PROCESSUS DE RAFFINEMENT les transf`erent au syst`eme par les courtiers fronti`eres Voici la sp´ecification de l’op ´eration publish() Les courtiers internes : la classe Broker La fonction computeGlobalFiltre() pour calculer un filtre unique qui couvre, en terme de l’ensemble des notifications le satisfaisant, tous les autres filtres enregistr ´es sur ce courtier De telle sorte, la fonction cover(f1, f2) retourne la valeur a` vrai si la filtre f1 couvre la filtre f2 Autrement dit, l’ensemble de notifications satisfaisant le filtre f1 couvre celui pour le filtre f2 Comme le cas de la fonction match(), la s ´emantique de ces fonctions d´epend bien de la d´efinition concr`ete d’un filtre Ainsi, on ne les utilise et non pas les sp´ecifie ici Lors de la demande de mettre a` jours la table de routage du a` un changement des souscriptions (la connexion d’un nouveau subscriber, la d´econnexion ou le change de filtre d’un subscriber), le courtier invoque l’op´eration updateSubscription(filtre : Filtre) chez ses voisins pour propager ce changement Ce processus de propagation est r´ealis´ de mani`ere r´ecursivement Dans cette version en OCL, cette op´eration ne remplace que le filtre du courtier correspondant stock´e dans la table de routage, ou ´eventuellement cr´eer une nouvelle entr´ee (´el´ement) de la table de routage De plus, la sp´ecification de l’op´eration updateSubscription() est diff´erente un peu pour les deux architecture de d´eploiement des courtiers Pour la topologie hi´erarchique, les mises a` jours de filtre ne CHAPITRE PROCESSUS DE RAFFINEMENT sont envoy´ees uniquement qu’au le courtier (( p`ere )) Par contre, on envoie le filtre chang´e aux tous les voisins, sauf que celui qui appel cette op´eration Voici la sp´ecification de cette op´eration associ´ee a` la topologie pair-a`-pair acyclique Pour la topologie hi´erarchique, la sp´ecification de cette op´eration est presque identique, mais on n’envoie la demande de mettre a` jour qu’au parent (il y en a seulement un pour chaque courtier) Pour deux topologies abord´ees dans cette section, cette di ff´erence se retrouve similai-rement dans la sp´ecification d’autres op´erations concernant la mise a` jour de la table de routage Il suffit donc de d´ecrire la sp´ecification des op´erations pour la topologie hi´erar-chique pair-a`-pair Lors de l’arriv´ee d’une nouvelle notification sur un courtier, celle-ci est transf´er´ee ensuite aux courtiers voisins qui s’y int ´eressent Cela est fait grˆace a` l’op´eration forwardNotification() CHAPITRE PROCESSUS DE RAFFINEMENT Les courtiers frontieres` : la classe BorderBroker Un courtier fronti`ere est une extension d’un courtier interne La classe BorderBroker est donc d´eriv´ee de la classe Broker, et elle contient ´egalement toutes les op´erations sp´e-cifi´ees ci-dessus La sp´ecification pour ces op´erations reste la mˆeme, sauf pour la fonction forwardNotification() car un courtier fronti`ere doit en plus v´erifier pour les subscribers locaux CHAPITRE PROCESSUS DE RAFFINEMENT Le gestionnaire appelle l’op´eration register() pour enregistrer une souscription sur le courtier fronti`ere auquel se connecte le subscriber L’op´eration unregister() sert a` un subscriber de retirer sa souscription sur le courtier CHAPITRE PROCESSUS DE RAFFINEMENT Le diagramme d’etats´ et le supporte de l’itinerance´ Au cours de sa mobilit´e, il se peut tr`es souvent qu’un client mobile sorte d’une zone de couverture d’un point d’acc`es (donc se d´econnecte du syst`eme) et entre dans une autre (reconnecter) Le syst`eme doit traiter cette situation de telle sorte que ses utilisateurs ne sentent pas (( la mobilit´e )) Autrement dit, du point de vue applicatif, le supporte de l’itin´erance est fait de mani`ere transparente, en assurant l’int´egralit´ des no-tifications correspondant, ainsi que l’ordre de la livraison D’autre part, la s´emantique du Publish/Subscribe d´efinie lors de la sp´ecification abstraite doit ˆetre toujours respec-t ´ee Notre solution s’appuie sur la modification du protocole entre les gestionnaires et les courtiers ; pour cela, le diagramme d’´etats est utilis´e Le diagramme d’´etats avec le diagramme de collaboration et la sp´ecification en OCL, est ´egalement employ´ pendant le processus de r´eification des abstractions de communi-cation pour la gestion de la dynamicit´e et du cycle de vie des gestionnaires Lors de la connexion/d´econnexion d’un composant au/du m´edium, le diagramme d’´etats est utilis´e pour d´eclencher localement dans un gestionnaire les actions n´ecessaires en fonction des occurrences de certains ev´enement Dans le cas du m´edium publish/subscribe, nous uti-lisons ce diagramme pour le supporte de l’itin´erance des clients mobiles Tout d’abord, quand un subscriber est hors de connexion avec le m´edium, son mode de souscription est automatiquement bascul´e vers pull-based ; pour activer la queue des notifications hors-lignes Lors de sa reconnexion, le gestionnaire g´en`ere automatiquement une souscription avec le mˆeme filtre que pr´ec´edemment, et aussi la r´ef´erence sur l’ancien courtier Voici la sp´ecification de l’op´eration g´erant la connexion des subscribers De cette fa¸con, le m´edium rafraˆıchit la table de routage sur les courtiers concern´es, pour s’adapter a` nouvelle localisation du subscriber Le processus de relocation du subscriber comprend ´eventuellement la livraison, toujours en ordre FIFO, des notifications correspondantes publi´ees pendant sa d´econnexion pour assurer de l’int´egralit´ de la livraison des notifications L’autre version de l’op´eration register(), avec la r´ef´erence sur un l’ancien courtier a` l’entr´ee, est utilis´ee par le gestionnaire dans le cas o`u il reconnaˆıt qu’il vient d’entrer dans un nouveau zone de couverture apr`es un p´eriode de d´econnexion CHAPITRE PROCESSUS DE RAFFINEMENT L’op´eration fetch() retourne les notifications dans la file d’attente d’une souscription, et puis la supprime Chapitre Conclusion Nous avons pr´esent´ notre contribution sur la communication dans les jeux en r´eseau mobile La solution s’appuie particuli`erement sur le Publish/Subscribe A partir du choix de mod`ele de communication, nous avons pr´esent´ le processus de r´eification de ces abstractions, de la sp´ecification abstraite de publish/subscribe, jusqu’au choix de conception Dans cette derni`ere ´etape, deux versions de gestion des souscriptions sont donn´ees : Gestion des souscriptions centralis´ees : le m´edium est pr´esent´ par les deux ges-tionnaires (ceux associ´es aux rˆoles) et le courtier qui joue le rˆole d’un interm´ediaire unique du syst`eme c’est lui qui g`ere les souscriptions, conduit les notifications des publishers vers les subscribers correspondants Gestion des souscriptions distribu´ees : a` cˆot´e des gestionnaires associ´es a` chaque rˆole, le m´edium comprend encore plusieurs courtiers (internes et externes) Dans cette version, nous avons propos´e ´egalement un algorithme de routage, avec le supporte de la mobilit´e (la connexion/d´econnexion, et aussi l’itin´erance des unit´es mobiles) N´eanmoins, il reste quelques limitations dans l’algorithme que nous avons propos´e Suppose que l’on impl´emente cet algorithme pour un jeu Un client est hors de connexion du syst`eme, et lors de sa reconnexion au syst`eme, comme l’algorithme du supporte de la mobilit´e le demande, il doit fournir les informations telles que la r´ef´erence sur l’ex-courtier, ainsi que le mode de souscription Cela force les clients a` utiliser toujours le mˆeme dispositif mobile (il ne peut pas mˆeme changer la m´emoire de cette unit´e mobile) D’autre part, restant au niveau sp´ecification, l’interd´ependant entre les classes dont la structure n’est pas clarifi´ee nous force de ne pas pouvoir d´ecrire l’algorithme tr`es clairement Finalement, le choix de conception que nous avons pr´esent´ convient non seulement aux jeux multijoueurs en r´eseau mobile, mais aussi pour toutes les applications dont les fonctionnements sont conduits par les ev´enements (les syst`emes de service de notifica-tions par exemple) Dans ces cas, le publish/subscribe s’av`ere un bon candidat pour tels applications, surtout dans contexte mobile 59 Annexe : Specification´ OCL des services apres` la premiere` etape´ L’operation´ subscribe L’operation´ unsubscribe 60 CHAPITRE CONCLUSION L’operation´ pull L’operation´ publish Annexe : Specification´ OCL des services du medium,´ version centralisee´ Les services de la classe Broker L’operation´ publish L’operation´ initSupscription 62 CHAPITRE CONCLUSION L’operation´ subscribe L’operation´ unsubscribe Annexe : Discussion supplementaire´ sur la table de routage Il existe, en effet, deux types de routage : Routage direct : pour les subscribers localement associ´es a` un courtier fronti`ere, sur les courtiers internes, il n’existe pas ce type de routage Sur le diagramme de collaboration, cela est pr´esent´ par la classe Subscription et ses associations avec d’autres classes Routage (( interm´ediaire )) : le courtier d´etermine le chemin qu’une notification doit emprunter afin d’atteindre les subscribers correspondants, mais non directement accessibles Les courtiers fronti`eres maintiennent donc deux tables de routage : l’un de type direct et l’autre pour les souscriptions non directement accessibles Par contre, les courtiers internes n’en g`erent qu’une - le deuxi`eme type En ce qui concerne la maintenance et la gestion des tables de routage, la solution est assez simple pour le premier type de routage On peut stocker l’identification d’un subscriber avec son filtre dans une liste des souscriptions sur le courtier La mise `a jour est simplement r´ealis´ee par l’ajout/la suppression d’un el´ement de cette liste Au contraire, le deuxi`eme demande une solution un peu plus sophistiqu´ee De ce fait, dans ce document, le terme de table de routage fait implicitement r´ef´erence au routage interm´ediaire Naturellement, on peut penser construire une table de routage comme une liste dont chaque el´ement est une paire (F, C) ; F pour le filtre et C est le chemin comprenant les courtiers interm´ediaires, par lesquels les notifications satisfaisant le filtre F doivent passer pour arriver aux subscribers correspondants On rappelle que dans une architecture pair-`apair connexe et acyclique, il n’existe qu’un chemin unique reliant deux courtiers di ff´erents De ce fait, l’avantage d’une telle solution est que la latence est consid´erablement r´eduite, car on ne doit invoquer la fonction de correspondance qu’une seul fois chez le courtier qui re¸coit directement la notification d’un publisher Cette notification est ensuite envoy´ee par le chemin C jusqu’au subscriber qui a d´efini le filtre F Mais l’agrandissement de taille de la table de routage lors de l’augmentation de nombre de participants rend cette solution infaisable (pour un syst`eme `a grande ´echelle, plusieurs milliers voire dizaines de milliers de subscribers) A Carzaniga, D S Rosenblum, et A L Wolf [28] ont propos´e une strat ´egie de routage (( couverture )) : pour les subscribers d’un mˆeme courtiers (ayant le 64 CHAPITRE CONCLUSION mˆeme chemin C ), si le filtre F1 accepte les notifications correspondant au filtre F2, il est inutile de faire suivre ce dernier aux courtiers voisins Dans la plupart de cas, cela r´eduit significativement la taille de la table de routage Si aucune couverture n’est trouv´ee, on peut fusionner les filtres existants pour cr´eer un nouveau [30], et seulement le dernier sera enregistr´ dans la table de routage sur les autres courtiers voisins Dans notre sp ´ecification, nous avons choisit a` construire la table de routage couverture Bibliographie [1] S Caltagirone, M Keys, B Schlief, M Jane Willshire Architecture for a Massively Multiplayer Online Rˆole Playing Game Engine Consortium for Computing Sciences in Colleges 2002 [2] D Saha, S Sahu, A Shaikh A Service Platform for On-Line Games Net-Games 2003, USA [3] S Fiedler, M Wallner, M.Weber A Communication Architecture for Mas-sive Multiplayer Games NetGames 2002, Germany [4] E Cronin, B Filstrup, A Kurc A Distributed Multiplayer Game Server System IEEE 2001 [5] A G´erodolle, F Dang Tran, L Garcia-Banuelos A Middleware Approach to building Large-Scale Open Shared Virtual Worlds IEEE 2000 [6] F Dang Tran, M Deslaugiers, A G´erodolle, L Hazard, N Rivierre An Open Middleware for Large-Scale Networked Virtual Environments IEEE 2002 [7] F Fitzek, Gerrit Schulte, M Reisslein System Architecture for Billing of Multi-Player Games in a Wireless Environment using GSM/UMTS and WLAN Service NetGames 2002, Germany [8] A.E Saddik, A.Dufour Peer-to-Pear Suitability for Collaborative Multi- player Games IEEE 2003 [9] C Diot, L Gautier A distributed Architecture for Multiplayer Interactive Applications on the Internet IEEE 1999 [10] Webopedia - The online dictionary and search engine for computer and Internet technology definitions : http://www.webopedia.com/ [11] E Cronin, B Filstrup, A Kurc Quake’s technical report University of Mi- chigan, 2001 http://warriors.eecs.umich.edu/games/papers/quakefinal.pdf [12] Quazal Multiplayer Connectivity : http://www.quazal.com [13] E Cronin, B Filstrup, A R Kurc, S Jamin An Efficient Synchronization Mechanism for Mirrored Game Architectures NetGames 2002, Germany [14] M Mauve How to Keep a Dead Man from Shooting 66 BIBLIOGRAPHIE [15] L Gautier et C Diot Design and Evaluation of MiMaze, a Multi-Player Game on the Internet Proc IEEE Multimedia (ICMCS’98), Austin, TX, USA, 1998, pp 233-236 [16] K Fujikaway, A Itohyy, S Shimojoyyy, et H Miyahara Synchronization Issues on Networked Virtual Environments of Large-Scale Multiparty Ap-plications Technical report of IEICE The Institute of Electronics, Infor-mation and Communication Engineers Japan 2003 [17] Middleware FAQ : http://middleware.internet2.edu/overview/middleware-faq.html [18] TerraPlay system : http://www.terraplay.com/ [19] ButterFly.net : http://www.butterfly.net [20] M´edium : http://www-info.enst-bretagne.fr/medium [21] E Cariou Contribution a` un processus de reification d’abstractions de com-munication th`ese, Universit´ de Rennes 1, France 2003 [22] Y Liu, B Plate Survey of Publish Subscribe Event Systems Computer Science Dept, Indian University [23] AR Bharambe, S Rao, S Seshan Mercury : A Scalable Publish- Subscribe System for Internet Games NetGames2002, Germany 2002 [24] Wikipedia, the free encyclopedia : http://en.wikipedia.org/wiki/Main Page [25] Y Huang, H Garcia-Molina Publish/Subscribe in a Mobile Environment Department of Computer Science, University of Stanford [26] R Meier Communication Paradigms for Mobile Computing Mobile Com-puting and Communications Review, Volume 6, Number [27] Q Wang, H Wang, H Tang, G Dai Adaptive Real-Time Publish-Subscribe Service Model for Mobile Communication Environments IEEE 2003 [28] M Caporuscio, A Carzaniga, A.L Wolf Design and Evaluation of a Sup-port Service for Mobile, Wireless Publish/Subscribe Applications IEEE 2003 [29] G Cugola, H Jacobsen Using Publish/Subscribe Middleware for Mobile Systems Mobile Computing and Communications Review, Volume 6, Num-ber [30] L.Fiege, F C Gartner, O Kasten, A Zeidler Supporting Mobility in Content-Based Publish/Subscribe Middleware Federa-tion for Information Processing 2003 IFIP International [31] G Muhl Large-Scale Content-Based Publish/Subscribe Systems Ph.D the-sis, Darmstadt University of Technology, Germany 2002 BIBLIOGRAPHIE [32] P.Th Eugster, P Felber, R Guerraoui, A.-M Kermarrec The many face of Publish/Subscribe ACM Computing Surveys, Vol 35, No 2, June 2003, pp 114-131 [33] A Carzaniga Architectures for an Event Notification Service Scalable toWide-area Networks Ph.D thesis, POLITECNICO DI MILANO, Italy 2003 [34] A Virgillito Publish/Subscribe Communication Systems : from Models to Applications Ph.D thesis, Universit`a degli Studi di Roma “La Sapienza”, Italy 2003 [35] D Powell Group communication Communications of the ACM, 39(4) :50-97, April 1996 [36] http://www.commentcamarche.net/wifi/wifiintro.php3 [37] M H Dunham, A Helal Mobile computing and Database : Anything New ? SIGMOD Record, Association for Computing Machinery, 1995 [38] A Zeidler, L Fiege Mobility Support with REBECA IEEE 2003 [39] http://grouper.ieee.org/groups/802/11/ [40] http://www.weca.org/ [41] A Carzaniga, D Rosenblum, A L Wolf Interfaces and Algorithms for a Wide-Area Notification Service University of Colorado, Technical Report CU-CS-888-99, 1999 [42] MicroSoft NET : http://www.microsoft.com/net/ [43] Java Message Sevices : http://java.sun.com/products/jms/ [44] CORBA Notification Service http://www.omg.org/technology/documents/formal/notification service.htm [45] Antoine Beugnard Les abstractions de communication dans les jeux en R´eseau mobile Sujet de stage DEA 2004 http://www-info.enstbretagne.fr/Stages/Propositions-Stage-DEA-2004/Abstractioncommunication.html [46] Michel Simatic Support des donn´ees persistantes pour des applications de type jeux massivement en r´eseau Sujet de stage de DEA Informatique 2003-2004, D´epartement Informatique - Institut National des T´el´ecommunica-tions a` Evry ... particuli`erement dans les environnements mobiles Dans les jeux massivement multijoueurs, plus la communication entre les joueurs est efficace, plus de joueurs peuvent participer au jeu Ainsi, la communication. .. physique, pour les en retirer (y compris ´eventuellement le ´ CHAPITRE ETAT DE L’ART temps pour les encrypter et les d´ecrypter, bien entendu, cela augmente ´egalement la latence !) La latence de transmission... r´eseaux mobiles N´eanmoins, la plupart des jeux actuellement offerts sur mobiles sont des jeux monojoueurs Pour les jeux multijoueurs, il en existe sur internet de nombreux exemples, mais ils restent