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´e 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´ecommunication de Bretagne, de m’avoir bien encadr´e 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 R´esum´e Notre travail est men´e dans le cadre du projet de recherche MEGA (Mobile MultiPlayEr Game Architecture) qui a pour but de r´ealiser une infrastructure visant aux d´eveloppeurs 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´e 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 communication du mod`ele Publish/Subscribe Nous proposons ´egalement deux choix de conception 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 effective ; 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 communication 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 implementations 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 mati`eres Introduction 1.1 Contexte du stage 1.2 L’objectif du stage 1.3 Le M´edium et le processus de r´eification d’Abstractions 1.4 Organisation du document de Communication ´ Etat de l’Art 2.1 Les types des jeux en ligne 2.2 Architecture 2.2.1 Topologie de r´eseau 2.2.1.1 Client-Serveur 2.2.1.2 Pair-`a-Pair 2.2.1.3 Hybride 2.2.2 Architecture logiciel 2.2.2.1 Intergiciel 2.2.2.2 Mod`ele Publish/Subscribe 2.3 Verrous techniques 2.3.1 La latence dans les jeux en ligne 2.3.2 Synchronisation et consistance 2.3.2.1 Dead reckoning - DR 2.3.2.2 Bucket Synchronization avec DR (BS) et Stop-and-wait Synchronization (SWS) 2.3.2.3 Time Warp Synchronization (TWS) et Trailing State Synchronization (TSS) 2.4 Les plates-formes existantes 2.4.1 Continuum 2.4.2 TerraPlay 2.4.3 ButterFly 2.5 Conclusion 7 10 10 12 12 12 13 14 14 14 15 15 15 17 17 18 19 20 20 21 23 25 Environnements mobiles et Mod` ele de Communication 26 3.1 Infrastructure Mobile 27 ` TABLE DES MATIERES 3.2 3.3 3.4 3.1.1 R´eseau sans fils 3.1.2 Architecture des r´eseaux WLANs 3.1.3 Mod`ele de calculs mobiles 3.1.4 Caract´eristiques des environnements mobiles Le mod`ele Publish/Subscribe 3.2.1 Les ´el´ements dans un syst`eme publish/subscribe 3.2.2 Mod`ele de souscription 3.2.2.1 Mod`ele bas´e sur sujet 3.2.2.2 Mod`ele bas´e sur contenu 3.2.2.3 Mod`ele bas´e sur type 3.2.3 Architecture du syst`eme 3.2.3.1 Topologie hi´erarchique 3.2.3.2 Architecture pair-`a-pair 3.2.3.3 Architecture hybride Sp´ecification abstrait du m´edium PublishSubscribeMedium 3.3.1 Description informelle et listes des services 3.3.2 Diagramme de collaboration du m´edium Publish/Subscribe 3.3.3 Sp´ecification OCL Conclusion Processus de raffinement 4.1 Premi`ere ´etape : introduction des gestionnaires de 4.2 Deuxi`eme ´etape : Choix de conception 4.2.1 Gestion centralis´ee des souscriptions 4.2.1.1 Diagramme de collaboration 4.2.2 Gestion distribu´ee des souscription 4.2.2.1 Algorithme de routage 4.2.2.2 Diagramme de collaboration 4.2.2.3 Sp´ecification OCL rˆole 27 27 28 29 30 30 32 32 33 34 34 35 35 36 36 37 37 39 42 43 43 45 45 45 47 47 50 52 Conclusion 59 Annexe : Sp´ ecification OCL des services apr` es la premi` ere ´ etape 60 Annexe : Sp´ ecification OCL des services du m´ edium, version centralis´ ee 62 Annexe : Discussion suppl´ ementaire sur la table de routage 64 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 L’effet de la latence L’ex´ecution du remorquage d’´etat de synchronisation dans TSS (Quake) 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 13 16 19 21 21 22 22 24 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 Mod`ele Publish/Subscribe de base d´ecoupage de l’espace d’interaction dans un syst`eme Publish/Subscribe 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 29 30 31 31 32 35 36 36 38 39 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 44 44 46 46 46 48 49 49 51 52 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 Vue dynamique apr`es l’introduction des gestionnaires La relation entre des cuortiers dans la topologie hi´erachique et pair-`a-pair acyclique La construction de la table de routage en pair-`a-pair acyclique Second choix de conception : gestion distribu´ee Vue dynamique de la version distribu´ee, le cas de message subscribe La construction de la table de routage en hi´erachique 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’offre 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 communication 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, efficacit´e, etc.) CHAPITRE INTRODUCTION 1.3 Le M´edium et le processus de r´eification 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´eifie1 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 mettra `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 abstraite 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´e qui fait partie du syst`eme Le processus de raffinement suivant consiste `a transformer cette sp´ecification abstraite `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´e 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´ementation – Choix de d´eploiement : il s’agit de d´efinir l’architecture de d´eploiement des gestionnaires 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´e 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´e dans chapitre Le dernier chapitre est une conclusion du document CHAPITRE PROCESSUS DE RAFFINEMENT 54 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 diff´erence se retrouve similairement 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´erarchique 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 55 Les courtiers fronti`eres : 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´ecifi´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 56 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 57 Le diagramme d’´etats et le supporte de l’itin´erance 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´e des notifications 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 respect´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´e pendant le processus de r´eification des abstractions de communication 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 utilisons 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 horslignes 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´e 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 58 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´e 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´e 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´e par les deux gestionnaires (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´e 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 notifications par exemple) Dans ces cas, le publish/subscribe s’av`ere un bon candidat pour tels applications, surtout dans contexte mobile 59 Annexe : Sp´ecification OCL des services apr`es la premi`ere e´ tape L’op´eration subscribe L’op´eration unsubscribe 60 CHAPITRE CONCLUSION L’op´eration pull L’op´eration publish 61 Annexe : Sp´ecification OCL des services du m´edium, version centralis´ee Les services de la classe Broker L’op´eration publish L’op´eration initSupscription 62 CHAPITRE CONCLUSION L’op´eration subscribe L’op´eration unsubscribe 63 Annexe : Discussion suppl´ementaire 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´e 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 diff´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 65 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´e 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 NetGames 2003, USA [3] S Fiedler, M Wallner, M.Weber A Communication Architecture for Massive 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 Multiplayer 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 Michigan, 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 67 [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 Applications Technical report of IEICE The Institute of Electronics, Information and Communication Engineers Japan 2003 [17] Middleware FAQ : http://middleware.internet2.edu/overview/middlewarefaq.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 communication th`ese, Universit´e 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 Computing 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 Support 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, Number [30] L.Fiege, F C Gartner, O Kasten, A Zeidler Supporting Mobility in Content-Based Publish/Subscribe Middleware IFIP International Federation for Information Processing 2003 [31] G Muhl Large-Scale Content-Based Publish/Subscribe Systems Ph.D thesis, Darmstadt University of Technology, Germany 2002 BIBLIOGRAPHIE 68 [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) :5097, 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://wwwinfo.enst-bretagne.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 20032004, D´epartement Informatique - Institut National des T´el´ecommunications `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. .. que, les sujets qui regroupent les ´ev´enements pr´esentent des caract´eristiques communes non seulement dans le contenu, mais ´egalement en structure Les ´ev´enements ne sont plus classifi´es en. .. pour les en retirer (y compris ´eventuellement le ´ CHAPITRE ETAT DE L’ART 17 temps pour les encrypter et les d´ecrypter, bien entendu, cela augmente ´egalement la latence !) La latence de transmission