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

Notre travail est men´e dans le cadre du projet de recherche MEGA Mobile PlayEr Game Architecture qui a pour but de r´ealiser une infrastructure visant aux d´e-veloppeurs des jeux massiv

Les Abstractions de Communication dans

R´ealis´e par

LE Van Tuan Promotion 8, IFI

EncadrantAntoine BEUGNARD

D´epartement InformatiqueEcole National Sup´erieur des T´el´ecommunications de Bretagne

France, Oct 2004

Je tiens `a remercier particuli`erement Monsieur Michel SIMATIC, responsable du projetMEGA, de m’avoir accueilli au sein de son ´equipe.

Je tiens `a remercier sinc`erement Monsieur Charles DURAND, directeur de l’IFI, dem’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´e-communication de Bretagne, de m’avoir bien encadr´e pendant toute la dur´ee de monstage

Je remercie vivement tous les personnels de l’IFI, qui m’ont aid´e pendant mon cursusd’´etudes

Finalement, un grand merci `a tous les personnels du D´epartement Informatique del’ENST Bretagne, `a toutes les membres du projet MEGA, notamment aux stagiaires aulaboratoire informatique, ENST Bretagne, qui m’ont port´e leur amiti´e

1

Notre travail est men´e dans le cadre du projet de recherche MEGA (Mobile PlayEr Game Architecture) qui a pour but de r´ealiser une infrastructure visant aux d´e-veloppeurs des jeux massivement multijoueurs, particuli`erement dans les environnementsmobiles.

Multi-Dans les jeux massivement multijoueurs, plus la communication entre les joueurs estefficace, plus de joueurs peuvent participer au jeu Ainsi, la communication est un despoints cruciaux pour le succ`es d’un jeu L’impl´ementation du mod`ele de communicationClient/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 teraction entre les participants, ainsi facilite la reconfiguration et l’´evolution du syst`eme

d’in-Il est donc consid´er´e comme une architecture d’intergiciel valable pour les applicationsfonctionnant en se basant sur les ´ev´enements (c’est le cas de jeu multijoueur) Il existedans 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 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 del’itin´erance sp´ecifique `a la conception distribu´ee est discut´e

commu-Mots-cl´es : Abstractions de communication, architecture et composant, support de

la mobilit´e dans Publish/Subscribe , jeux multijoueurs, service de notification

2

Our work is undertaken within the framework of the research project MEGA (MobileMultiplayEr 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 thecrucial 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 inthe mobile context The Publish/Subscribe system increases cutting space of interactionbetween the participants, hence facilitates the reconfiguration and the evolution of thesystem It is thus regarded as a valuable middleware architecture for the event-drivenapplications (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 staticsystems rather than mobile We thus propose to use this model of communication for thegame multiplayer in mobile network

In this report, we present a process of reification of communication abstractions ofthe 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 thedistributed design is discussed

Keywords : Abstractions of Communication, Structures and Composing, Support ofMobility in Publish/Subscribe, Game Multiplayer, Service of Notification

3

1 Introduction 7

1.1 Contexte du stage 7

1.2 L’objectif du stage 7

1.3 Le M´edium et le processus de r´eification d’Abstractions de Communication 8 1.4 Organisation du document 9

2 Etat de l’Art´ 10 2.1 Les types des jeux en ligne 10

2.2 Architecture 12

2.2.1 Topologie de r´eseau 12

2.2.1.1 Client-Serveur 12

2.2.1.2 Pair-`a-Pair 13

2.2.1.3 Hybride 14

2.2.2 Architecture logiciel 14

2.2.2.1 Intergiciel 14

2.2.2.2 Mod`ele Publish/Subscribe 15

2.3 Verrous techniques 15

2.3.1 La latence dans les jeux en ligne 15

2.3.2 Synchronisation et consistance 17

2.3.2.1 Dead reckoning - DR 17

2.3.2.2 Bucket Synchronization avec DR (BS) et Stop-and-wait Synchronization (SWS) 18

2.3.2.3 Time Warp Synchronization (TWS) et Trailing State Syn-chronization (TSS) 19

2.4 Les plates-formes existantes 20

2.4.1 Continuum 20

2.4.2 TerraPlay 21

2.4.3 ButterFly 23

2.5 Conclusion 25

3 Environnements mobiles et Mod`ele de Communication 26 3.1 Infrastructure Mobile 27

4

3.1.1 R´eseau sans fils 27

3.1.2 Architecture des r´eseaux WLANs 27

3.1.3 Mod`ele de calculs mobiles 28

3.1.4 Caract´eristiques des environnements mobiles 29

3.2 Le mod`ele Publish/Subscribe 30

3.2.1 Les ´el´ements dans un syst`eme publish/subscribe 30

3.2.2 Mod`ele de souscription 32

3.2.2.1 Mod`ele bas´e sur sujet 32

3.2.2.2 Mod`ele bas´e sur contenu 33

3.2.2.3 Mod`ele bas´e sur type 34

3.2.3 Architecture du syst`eme 34

3.2.3.1 Topologie hi´erarchique 35

3.2.3.2 Architecture pair-`a-pair 35

3.2.3.3 Architecture hybride 36

3.3 Sp´ecification abstrait du m´edium PublishSubscribeMedium 36

3.3.1 Description informelle et listes des services 37

3.3.2 Diagramme de collaboration du m´edium Publish/Subscribe 37

3.3.3 Sp´ecification OCL 39

3.4 Conclusion 42

4 Processus de raffinement 43 4.1 Premi`ere ´etape : introduction des gestionnaires de rˆole 43

4.2 Deuxi`eme ´etape : Choix de conception 45

4.2.1 Gestion centralis´ee des souscriptions 45

4.2.1.1 Diagramme de collaboration 45

4.2.2 Gestion distribu´ee des souscription 47

4.2.2.1 Algorithme de routage 47

4.2.2.2 Diagramme de collaboration 50

4.2.2.3 Sp´ecification OCL 52

Annexe 1 : Sp´ecification OCL des services apr`es la premi`ere ´etape 60 Annexe 2 : Sp´ecification OCL des services du m´edium, version centralis´ee 62 Annexe 3 : Discussion suppl´ementaire sur la table de routage 64

2.1 Topologies de r´ eseaux 13

2.2 L’effet de la latence 16

2.3 L’ex´ ecution du remorquage d’´ etat de synchronisation dans TSS (Quake) 19

2.4 L’architecture en couche de Continuum. 21

2.5 Les composants dans un jeu construit sur TerraPlay 21

2.6 Une architecture typique d’un jeu sur TerraPlay 22

2.7 La communication dans syst` eme TerraPlay 22

2.8 Architecture de ButterFly 24

3.1 Mod` ele de calcul mobile 29

3.2 Mod` ele Publish/Subscribe de base 30

3.3 d´ ecoupage de l’espace d’interaction dans un syst` eme Publish/Subscribe 31

3.4 d´ ecoupage d’´ ecoulement 31

3.5 d´ ecoupage de temps 32

3.6 Architecture hi´ erachique 35

3.7 Architecture pair-` a-paire acyclique et pair-` a-pair g´ en´ erale 36

3.8 Architecture hybride 36

3.9 Diagramme de collaboration du m´ edium Publish/Subscribe 38

3.10 Vue dynamique du m´ edium Publish/Subscribe 39

4.1 Introduction des gestionnaires sur le diagramme de collaboration 44

4.2 Vue dynamique apr` es l’introduction des gestionnaires 44

4.3 Premi` ere choix de conception : gestion centralis´ ee 46

4.4 Vue dynamique de version centralis´ ee : le cas de service subscribe 46

4.5 Vue dynamique de version centralis´ ee : le cas de service publish 46

4.6 La relation entre des cuortiers dans la topologie hi´ erachique et pair-` a-pair acyclique 48

4.7 La construction de la table de routage en pair-` a-pair acyclique 49

4.8 La construction de la table de routage en hi´ erachique 49

4.9 Second choix de conception : gestion distribu´ ee 51

4.10 Vue dynamique de la version distribu´ ee, le cas de message subscribe 52

6

1.1 Contexte du stage

Aujourd’hui les dispositifs mobiles et sans fils sont omnipr´esents, avec de nombreusesapplications Il apparaˆıt rapidement et clairement que le divertissement sera une de cesapplications majeures des futurs r´eseaux mobiles N´eanmoins, la plupart des jeux actuelle-ment offerts sur mobiles sont des jeux monojoueurs Pour les jeux multijoueurs, il en existesur internet de nombreux exemples, mais ils restent limit´es en nombre de joueurs (tout auplus quelques centaines)[46] Ici, nous nous int´eressons au domaine des jeux sur mobile etmassivement multijoueurs (plusieurs milliers voire dizaines de milliers de joueurs).Afin de r´eduire le travail de d´eveloppement des jeux multijoueurs, on voudrait ˆetrecapable de sp´ecifier et r´ealiser une infrastructure logicielle (un intergiciel), g´erant les pro-bl`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 unetelle infrastructure Ce projet vient de d´ebuter, un ´etat de l’art de l’offre des intergicielsexistants (Butterfly, Continuum, Terraplay, etc.) est donc n´ecessaire, l’id´eal ´etant

de s’appuyer sur une norme des notions offertes (inexistante actuellement) [45]

et non fonctionnelles (robustesse, efficacit´e, etc.)

7

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 informationsn´ecessaires `a l’aide de composants de communication Afin de diff´erencier des autres com-posants du syst`eme (les composants m´etiers, ou les composants fonctionnels, etc.), AntoineBeugnard 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 oud’interaction qui r´eifie1 une abstraction de communication )) Un m´edium peut impl´e-menter une abstraction de communication, un protocole consensus par exemple Dans lasuite du stage, nous allons(( r´eifier )) des abstractions de communication dans les jeux enr´eseau mobile selon le processus ´egalement propos´e par A Beugnard et E Cariou[21] Ceprocessus consiste `a transformer des abstractions de communication, `a partir de niveauconception le plus abstrait, sous forme de composants logiciels Quelque soit le niveau demanipulation, il permet de r´eserver l’unit´e et la coh´erence d’une abstraction d’interactionpendant tout le cycle de d´eveloppement d’une application

Le premier pas de ce processus est de d´eterminer les services que ce composant tra `a disposition des autres composants ; et aussi les services requis par le m´edium pourfonctionner 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 mald´efinie ))[21] Dans ce pas, le m´edium est vu comme un unique entit´e qui fait partie dusyst`eme Le processus de raffinement suivant consiste `a transformer cette sp´ecification abs-traite `a plusieurs variantes d’impl´ementation en fonction du contexte d’utilisation, `a tousles niveaux du cycle de vie du logiciel, en continuellement respectant le contrat d’usage dum´edium d´etermin´e lors du niveau le plus abstrait Il s’agit l`a du contrat de la r´ealisation

met-en terminologie de UML Componmet-ent Voici trois ´etapes du processus de r´eification desabtractions :

– 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 lem´edium lors de d´eploiement

– Choix de conception : le r´esultat de cette ´etape est une sp´ecification d’impl´tion

ementa-– Choix de d´eploiement : il s’agit de d´efinir l’architecture de d´eploiement des naires du m´edium

gestion-A chaque ´etape de ce processus, des diagrammes de collaboration UML sont utilis´espour d´ecrire l’aspect structurel du m´edium, mettre en ´evidence la s´emantique et le com-portement dynamique de chacun des services du m´edium au niveau sp´ecification Dans laderni`ere ´etape, le diagramme de d´eploiement est employ´e pour chaque type de d´eploie-ment d´efini Outre, des contraintes OCL, des diagrammes d’´etats sont utilis´es en plus

1 La r´ eification est l’op´ eration de transformation en quelque chose de concret.

pour une sp´ecification plus claire du m´edium Dans le cardre du stage, nous ne r´ealiseronsque deux premiers ´etapes.

1.4 Organisation du document

L’´etat de l’art dans le chapitre 2 donne une vue g´en´erale sur la situation actuelle desjeux multijoueurs Les verrous techniques rencontr´es pour pouvoir mettre en ouevre unjeu massivement multijoueurs sont ´egalement discut´es dans ce chapitre A partir de cettediscusion, 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 estd´ecrit dans le chapitre 3 Ensuite, le processus de (( r´eification )) des abstractions decommunication du Publish/Subscribe s’est retrouv´e dans chapitre 4 Le dernier chapitreest une conclusion du document

´Etat de l’Art

Les jeux vid´eo tiennent une place tr`es importante dans l’informatique industrielle, del’ordre de millions de dollars par ann´ee industrielle au Japon, et double aux Etats-Unix.Dans ces prochaines ann´ees avec l’explosion de l’Internet, le jeu en ligne sera certainement

un segment croissant rapidement de l’industrie de jeu vid´eo Mais avant que les futursjeux en ligne puissent simuler la r´ealit´e avec plus de pr´ecision, ils doivent ˆetre capables desupporter les interactions entre les comp´etiteurs en temps r´eels Dans ce chapitre, nousd´ecrivons tout d’abord la situation actuelle des jeux en ligne, ainsi que les obstacles queles d´eveloppeurs de ce type d’application doivent surmonter Puis quelques points sur lesarchitectures sur lesquelles les jeux sont construits Finalement, comme le but du projetMega est la r´ealisation d’une plate-forme pour les jeux massivement multijoueurs, lesplates-formes telles que TerraPlay, Continuum, ButterFly, etc sont abord´ees Las´ecurit´e de communication est actuellement hors de discussion de ce chapitre

2.1 Les types des jeux en ligne

Avec des processeurs plus puissants, de nouveaux acc´el´erateurs 3D, les jeux sont deplus en plus sophistiqu´es, plus r´ealistes et donc plus attrayants Ils essaient d’attirer lesjoueurs non seulement par l’aspect multim´edia mais aussi en leur donnant l’impression de

se plonger dans un monde virtuel, faire face aux adversaires humains se situant au bout

du monde Cela modifie consid´erablement les habitudes des joueurs Ils ont actuellementtendance `a se pr´esenter dans un tr`es vaste espace - un champ de bataille virtuel avecnombre participants partout dans le monde par exemple Malheureusement, les actuelsjeux en ligne sont limit´e en nombre de joueurs, tous au plus quelques centaines Le pro-bl`eme apparaˆıt quand le nombre de participants du jeu augmente, le passage `a l’´echellereste donc le d´efi majeur pour ce type d’application

En fait, le degr´e de difficult´e d’adaptation `a l’augmentation du nombre de participantsd´epend de la nature du jeu Par exemple, un jeu de type actions en temps r´eels et ayantl’architecture pure client-serveur est impossible d’avoir plus de centaines de joueurs dans

le contexte actuel d’Internet Selon l’encyclop´edie Wikipedia [24], il y a quatre classes

10

principales de jeux en ligne : First-person shooters (FPS), Massive Multiplayer OnlineRole-Playing Games (MMORPG), Turn-based, et Real-time strategy (RTS).

FPS est un genre de jeux vid´eo combinant les actions de jeu vid´eo avec la vision dumonde sur l’´ecran qui simule celle du personnage Trois jeux tr`es connus, Doom,Quake et Half-Life font partie de cette classe Ce type de jeu en ligne fournit unmonde virtuel en temps r´eel Les actions des joueurs doivent instantan´ement ˆetrerefl´et´ees dans le monde virtuel, aux vues de tous les joueurs concurr´es par cetteaction, quelque soit leur position g´eographique Les jeux de ce type restent donclimit´es `a quelques dizaines de joueurs actuellement

MMORPGs sont les mondes persistants virtuels situ´es sur l’Internet Ils sont un ensemble sp´ecifique de jeux en ligne massivement multijoueurs dans lesquels lesjoueurs agissent l’un sur l’autre par l’avatar, c.-`a-d., une repr´esentation graphique

sous-du personnage qu’ils jouent Ces jeux ne demandent pas d’exigences strictes activit´e comme les pr´ec´edents N´eanmoins, le nombre de joueurs support´e n’atteintqu’au plus quelques centaines Sans exhaustivit´e, voici quelques exemples des jeuxMMORPG : Dragon Empires, EverQuest, EverQuest II, Warring Fac-tions, World of Warcraft, World War II Online

d’inter-Turn-based : Sid Meier’s Civilization, Heroes of Might and Magic, Chess,

Go, Othello, Risk, Diplomacy sont des jeux de type Turn-based, ´egalementconnus sous le nom de jeu de TBS (pour Turn-Based Strategy), dans lesquels chaquejoueur doit attendre son tour pour prendre une d´ecision, ou bien pour contrˆoler lepersonnage Une fois que chaque joueur a pris son tour, le tour se termine Pour

ce type de jeux en ligne, le nombre de joueurs n’est pas limit´e par la cation r´eseau, car un retard de la diffusion de nouvel ´etat est tol´erable pour lescomp´etiteurs

communi-RTS est un type de jeu vid´eo qui n’a pas des(( tours )) comme les jeux turn-based tionnels, mais le temps de jeu progresse en (( temps r´eel )) : c.-`a-d., il est continuplutˆot que discret Deux jeux de MicroSoft : Age of Empires et Empires : Rise

conven-of the Modern World font partie de ce type, mais le premier jeu RTS ´etait TheAncient Art of War de Evryware Warcraft, Empire Earth, Commandand Conquer, Total Annihilation, et StarCraft sont aussi les jeux RST po-pulaires En g´en´eral, les joueurs d’un jeu RTS suivent les trois pas (1) construire

un infrastructure de base : villageois, fermes, casernes, etc puis (2) collecter desressources, et ensuite, (3) attaquer les ennemis, essayer de d´etruire leur patrie, des’approprier leurs ressources Vers la fin du jeu, la charge de la communication r´eseauaugmente rapidement comme dans le cas de jeu FPS, mais ici, un joueur pourrait, `a

la fois, attaquer plus d’un ennemis, et ˆetre attaqu´e par les autres C’est donc coup plus difficile d’´etendre le nombre de participants Le jeu Massively MultiplayerOnline Real-Time Strategy (MMORTS) est une combinaison des jeux massivement

beau-multijoueur avec le jeu Real-time Strategy (par exemple : Shattered Galaxy, etMankind ).

La difficult´e du passage `a l’´echelle provient ´egalement du fait que l’Internet - un vironnement typiquement h´et´erog`ene - n’est pas capable de fournir une garantie d’unebasse latence, ce qui cause l’incoh´erence du jeu Par exemple, si deux joueurs sont tˆete

en-`

a tˆete, on ne peut pas avoir une situation o`u le joueur A pense qu’il a tu´e le joueur B,tandis que le joueur B pense qu’il a tu´e le joueur A Si on a des contradictions en cours

du jeu, c’est parce que le jeu n’est pas bien synchronis´e

Bref, la latence ´elev´ee, et l’incoh´erence qui en d´ecoule sont des obstacles primordiaux `asurmonter avant que les prochaines g´en´erations de jeux massivement multijoueurs en lignepuissent accomplir la transition aux mondes virtuels r´ealistes La plupart des ´etudes r´e-centes se concentrent sur la communication r´eseau et la synchronisation comme des pointscruciaux D’une part, on cherche un m´ecanisme efficace qui doit ˆetre assez intelligent pour

´eviter de(( bombarder )) le r´eseau, en n’envoyant que les informations n´ecessaires, et qu’`aceux qui s’y int´eressent D’autre part, des ´etudes sur les techniques de synchronisation telsque(( Bucket synchronization )), (( Stop-and-wait )), et (( dead reckoning )) sontr´ealis´ees parall`element afin d’´eviter l’incoh´erence du jeu lors de la perte, ou bien le retard

de messages transmis `a travers Internet Dans la suite de ce chapitre, nous pr´esentonsles techniques actuelles pour mettre en œuvre un jeu multijoueurs (et penser `a ce que onessaie de faire d’un niveau d’abstraction)

2.2 Architecture

2.2.1 Topologie de r´eseau

Les deux topologies de r´eseaux les plus communes pour construire les jeux sont leclient-serveur, et le pair-`a-pair Le client-serveur est conceptuellement plus simples etplus faciles `a mettre en œuvre que le pair-`a-pair

Les avantages de cette architecture pour les jeux en ligne sont que, en concentrantles calculs du nouvel ´etat du jeu sur le serveur, la (( triche )) peut donc ˆetre empˆech´ee

efficacement La coh´erence du jeu est totalement assur´ee, la seule chose dont les clientss’occupent est l’affichage du graphique des mondes simul´es fournis par le serveur Leserveur devient rapidement un point faible du syst`eme lorsque le nombre de participantsaugmente, pour deux raisons :

Passage `a l’´echelle : toutes les donn´ees sont convergentes sur le serveur De plus, commeles donn´ees doivent passer par le serveur pour aller aux autres, la latence est doncaugment´ee

Fragile aux fautes : dans tel syst`eme centralis´e, le serveur est un point sensible auxfautes Si tout `a coup, le serveur tombe en panne, le syst`eme est inutilisable

2.2.1.2 Pair-`a-Pair

Comme l’indique le nom, dans ce type de jeu, les clients communiquent en directchacun avec les autres, collectent des informations puis eux-mˆemes calculent l’´etat pr´esent

du jeu Les machines des clients sont d´el´egu´ees pour calculer le jeu, prendre des d´ecisions,

et acc´eder aux bases des donn´ees De ce fait, les tricheurs ont une chance d’intervenir dans

le jeu, de modifier le r´esultat, etc

Comme les messages sont transmis directement entre les clients, il n’y a pas de passagepar serveur La latence est donc r´eduite consid´erablement Mais on rencontre la mˆemesituation qu’avec les jeux ayant une architecture client-serveur : bien que les calculs dujeu soient r´epartis aupr`es de chaque client, le passage `a l’´echelle reste un probl`eme, carchaque client doit ´egalement envoyer lui-mˆeme les informations locales aux autres, etcollecter les ´etats des autres pour calculer les mises `a jours Le nombre des informationstransmises `a travers le r´eseau est donc le mˆeme dans les deux cas De plus, l’inconsistance

du jeu est plus difficile `a r´egler L’administration n’est maintenant plus concentr´ee commedans le cas du client-serveur

Fig 2.1 – Topologies de r´ eseaux

2.2.1.3 Hybride

En r´ealit´e, un syst`eme pur client-serveur, ou pair-`a-pair est rarement impl´ement´e Lasolution adopt´ee est un syst`eme hybride, celui-ci ayant l’architecture client-serveur commetopologie de r´eseau, mais la charge est r´epartie aupr`es des clients, et ne converge pas sur leserveur Dans un tel syst`eme, les clients sont autoris´es `a contrˆoler leur propre mouvement,

et puis `a leur tour, rapportent leur position au serveur qui mod´erera probablement lemouvement rapport´e, dans les cas n´ecessaires Autrement dit, le serveur joue le rˆole d’unarbitrer dont le travail est de juger l’´etat global du jeu S’il trouve une contradiction, alors ilintervient au jeu en appliquant un algorithme de synchronisation (discut´e ult´erieurement).Cela r´eduit consid´erablement le travail du serveur ; malheureusement, on rencontre encore

le probl`eme de la s´ecurit´e

Une autre variance est appel´ee Serveur-Refl´et´e (Mirrored-Server [11]) : plusieurs veurs sont ajout´es au syst`eme Les machines sp´ecialis´ees sont les serveurs du syst`emequi s’´etendent dans le monde entier, et qui peuvent ˆetre vus comme un serveur unique `al’ext´erieur du syst`eme Puisque il n’y a pas un seul serveur, le point unique d’´echec dusyst`eme est ´elimin´e Les clients prennent contact l’un avec l’autre au moyen des serveurscomme s’il n’y en avait qu’un Le m´ecanisme est presque transparent comme pour unsyst`eme client-serveur traditionnel A l’int´erieur, les serveurs communiquent directement

ser-de mani`ere pair-`a-pair Cette solution donne une meilleure latence de r´eseau en gardantl’administration chez l’exploitant du syst`eme Par contre, l’impl´ementation d’un tel sys-t`eme est plus complexe La communication entre les serveurs, entre les serveurs et lesclients demande un protocole sophistiqu´e pour la consistance du jeu

2.2.2 Architecture logiciel

2.2.2.1 Intergiciel

Intergiciel (middleware en anglais) est un terme informatique qui est employ´e pourd´ecrire un logiciel agissant en tant qu’interm´ediaire, ou en tant que membre d’un grouped’interm´ediaires, entre diff´erents composants qui ne fonctionnent pas tous sur les mˆemessyst`eme d’exploitation et ne sont pas ´ecrit dans les mˆemes langages Dans l’industrie dujeux, un intergiciel a pour but de faciliter les travaux des d´eveloppeurs de jeux en four-nissant une suite des robustes logiciels (les mod`eles graphiques, les textures, l’animation,

la communication r´eseau, etc.) Les intergiciels aident les d´eveloppeurs de jeux `a ne pass’´ecarter de leur m´etier de base Une bonne explication convenant bien au cas des jeux enligne provient du Middleware FAQs [17] : “Middleware is the intersection of the stuff thatnetwork engineers don’t want to do with the stuff that applications developers don’t want todo” TerraPlay[18], Continuum[5], et Quazal[12] sont des exemples de plates-formesexistantes, qui supportent les jeux massivement multijoueurs en lignes

mes-Les impl´ementations d’un mod`ele publisher/subscriber dans les syst`emes r´eels peuventdiff´erer les uns des autres, mais en g´en´eral, on peut les diviser en deux cat´egories princi-pales [3, 23] (1) bas´e sur sujet (suject-based) et (2) bas´e sur contenu (content-based).

La premi`ere cat´egorie organise les canaux de communication, appel´es ´egalement r´seau de communication, par lesquels un ensemble de messages sont transmis selon desconditions pr´ed´efinies Les publishers diffusent les messages en choisissant les canaux Onremarque que seuls les messages qui s’accordent avec le sujet d’un canal sont plac´es danscelui-ci Les subscribers, de leur cˆot´e, s’inscrivent aux canaux dont le sujet les int´eresse.Ensuite, ils re¸coivent tous les messages transmis par ces canaux

e-Dans le mode bas´e sur contenu, il n’existe plus la notion de canaux Les subscribersexpriment leur d´esir sur le contenu de messages qu’ils veulent recevoir, ce qui est r´ealis´e eng´en´eral par une requˆete Ce mode de communication est plus flexible [23], car il n’est pasn´ecessaire que les subscribers s´electionnent les canaux parmi ceux qui existent a priori.Mais l’impl´ementation pour ce mod`ele est plus compliqu´ee Pour la diffusion correctedes messages, on doit construire une fonction de correspondance (matching function)qui a pour but d’associer correctement les messages en provenance des publishers auxsubscribers L’algorithme bas´e sur sujet est plus simple `a impl´ementer que celui bas´e surcontenu

2.3 Verrous techniques

2.3.1 La latence dans les jeux en ligne

Afin de pouvoir r´epartir la charge des serveurs vers les clients dans un syst`eme serveur, les machines de joueur sont autoris´ees `a simuler le monde du jeu lui-mˆeme mais demani`ere synchronis´ee avec les autres Id´ealement, pour un instant d´etermin´e et au niveauglobal, toutes les simulations sur les machines chez les clients devraient ˆetre uniques (oupresque) du point de vue des joueurs Mais parfois, due `a la latence, la repr´esentation d’uneaction d’un joueur (appel´ee ´ev´enement) n’est pas totalement repr´esent´ee `a temps sur les

client-machines autres que celle qui l’a g´en´er´ee En cons´equence, l’inter-coh´erence est bris´ee Parexemple, dans un jeu multijoueur : Au moment t1, le joueur A commence `a s’avancer Lemessage est envoy´e par le r´eseau au serveur, il arrive au moment t2 un peu plus tard En cetinstant (t2 ), le serveur copie l’´etat du joueur A (s’avancer) Malheureusement, c’´etait d´ej`aderri`ere la position r´eelle de A (parce qu’il s’´etait avanc´e en moment t1 ) Maintenant leserveur annonce `a tous les clients que A avait commenc´e `a s’avancer Chaque participant,

y compris A, re¸coit le message `a l’instant t3 Et `a cause `a de la latence tous les clientssont maintenant encore derri`ere le serveur

Fig 2.2 – L’effet de la latence

Le dictionnaire Webop´edia [10] donne une d´efinition de la latence :

– En g´en´eral, c’est la p´eriode qu’un composant dans un syst`eme attendant un autrecomposant Donc, la latence est le temps gaspill´e Par exemple, pour l’acc`es desdonn´ees sur un disque, la latence est d´efinie par le temps que cela prend `a positionner

le secteur appropri´e sous la tˆete de lecture/´ecriture

– En terme de r´eseau, la latence est la quantit´e de temps que prend un paquet pour aller

de la source `a la destination Ensemble, la latence et la bande passants d´efinissent

la vitesse et la capacit´e d’un r´eseau

Dans les jeux multijoueurs, la latence est l’intervalle de temps entre l’action d’un joueur

et la repr´esentation de cette action sur le terminal de l’autre joueur (temps pour l’envoi,

et la r´eception des donn´ees), abaisser la latence a pour but d’assurer mieux la coh´erence

du jeu Au niveau r´eseau et application, il y a trois sources possibles de latence dans lesjeux en ligne en provenance d’infrastructure r´eseau [12] :

Latence de protocole r´eseau : le temps d’op´eration que le syst`eme met pour placerles donn´ees dans r´eseau physique, pour les en retirer (y compris ´eventuellement le

temps pour les encrypter et les d´ecrypter, bien entendu, cela augmente ´egalement

la latence !)

La latence de transmission : le temps pass´e pour envoyer des donn´ees `a travers ler´eseau jusqu’au r´ecepteur Comme dit dans la section pr´ec´edente, les jeux qui em-ploient la topologie client-serveur donnent les latences plus ´elev´ees que ceux ayantl’architecture pair-`a-paire En effet, les messages doivent passer par le serveur aulieu d’ˆetre envoy´es directement des exp´editeurs aux destinataires

Latence de traitement : c’est le temps que l’application met elle-mˆeme `a manipulerles donn´ees lors de l’envoi et lors de la r´eception

La question qui se pose est donc : que peut-on faire pour r´eduire la latence1, s’il estimpossible de faire circuler les informations `a travers le r´eseaux `a la vitesse ´egale ousup´erieure `a celle de la lumi`ere ?

2.3.2 Synchronisation et consistance

L’exemple pr´ec´edent montre que, `a cause de la latence, ce que le joueur A voit sur son

´ecran est diff´erent de ce que voient les autres La synchronisation est donc extrˆemementimportante dans un contexte distribu´e Cela a pour but d’assurer la coh´erence du jeu.Toujours sur le mˆeme l’exemple, apr`es avoir re¸cu le message du serveur indiquant sa nou-velle position, avec un effort de synchronisation du client A, il essayera de compenser ladiff´erence entre le message du serveur et son ´etat actuel en passant le personnage du client

A `a l’endroit o`u le serveur a indiqu´e qu’il devraient ˆetre Ainsi, le joueur A voit ses vements et ceux des autres sont saccad´es Cela est la cons´equence de l’application d’unetechnique de synchronisation nomm´ee (( Local presentation delay )), un des m´ecanismes

mou-de synchronisation le plus simple Cet effet peut ˆetre ´elimin´e en le combinant avec uneautre technique qui retarde l’affichage sur l’´ecran du joueur Cependant, les techniquesci-dessus ne conviennent pas aux applications plus sophistiqu´ees qui demandent des tech-niques de synchronisation plus complexes Dans la suite de cette section, nous pr´esentonsquelques m´ecanismes qui sont largement impl´ement´es dans les jeux (MiMaze, Quake,par exemple) [13, 15, 16]

contre la perte de messages envoy´es L’id´ee de base est de choisir `a l’avance un ensembled’algorithmes qui peuvent ˆetre employ´es par tous les noeuds des joueurs pour extrapoler

le comportement des entit´es dans le jeu, et choisir `a quel moment on doit permettre `al’application de r´ealiser ces algorithmes Dans le domaine du jeu, il y a deux cat´egories

de DR souvent utilis´ees : (1) pr´ediction de la position : proph´etise la nouvelle position

en se basant sur la position courante et la trajectoire de l’objet Et (2) la pr´edictiond’´ev´enements entr´es par les joueurs : l’entr´ee attendue est utilis´ee pour calculer la nouvelposition de l’objet

Afin de pouvoir utiliser DR dans des environnements virtuels distribu´es (EVD), on lespartitionne en des entit´es isol´es, une personne, une voiture, un avion ou une balle [14].Chacune de ces entit´es est contrˆol´ee par exactement une application participant dansEVD Les applications qui s’int´eressent `a une entit´e sont capables de pr´edire commentl’´etat de l’entit´e changera au cours du temps

On suppose qu’on applique le DR comme le m´ecanisme de synchronisation dansl’exemple de la section pr´ec´edente Le contrˆoleur de l’application du joueur A pr´evoit

sa nouvelle position au moment t2 Il pr´evient au serveur la nouvelle position pr´evue.Donc quand le serveur informe les autres de nouvelle position du joueur A, l’effet de lalatence est diminu´e Les mouvements des joueurs sont alors plus fluides Mais en r´ealit´e,l’action des joueurs n’est pas toujours pr´evisible Que se passera-t-il si le joueur changebrusquement de direction, ou de vitesse ? Martin Mauve donne deux exemples de contra-diction en appliquant le DR [14] : A Dead Man that Shoots (un homme mort qui tire) et

A Flying Tank (un tank volant)

Cependant, le DR est largement impl´ement´e dans les syst`emes distribu´es [14] pourdeux raisons (1) l’auto-pr´eparation : une transmission perdue sera compens´ee par uneautre transmission d’´etat pour la mˆeme entit´e (2) il n’a pas besoin d’une gestion centra-lis´ee des ´etats Chaque application est capable de g´erer localement les ´etats au moyen depr´ediction et de r´eception des mises `a jour d’´etat

2.3.2.2 Bucket Synchronization avec DR (BS) et Stop-and-wait Synchronization (SWS)

L’id´ee de base de ces techniques est de distinguer le temps r´eel de celui du jeu, ment dit, c’est une fa¸con de discr´etiser le temps Le temps dans le jeu est vu comme dess´eries d’intervalles Le nouvel ´etat n’est calcul´e qu’`a la fin d’un intervalle Ainsi, plus cetintervalle est court, plus les mouvements dans le jeu sont fluides

autre-BS divise le temps du jeu en s´eries d’intervalles constants Pendant un intervalle qui pourrait ˆetre assez long - un client collecte tous les mises `a jour des autres, les mes-sages (´ev´enements) collect´es sont plac´es dans un seau de synchronisation Tous les clientsdoivent attendre la fin de l’intervalle pour calculer le nouvel ´etat du jeu, les algorithmesd’extrapolation sont appliqu´es pour les messages perdus ou retard´es (technique DR) Cem´ecanisme est impl´ement´e dans le jeu MiMaze [9] MiMaze n’essaie pas de d´etecter lescontradictions ou de r´ecup´erer Il se peut que dans un seau, il y ait plus d’un ´ev´enement

-Mais seul celui qui est le plus r´ecent est ex´ecut´e Dans le cas o`u il n’y a aucun ´ev´enement,l’´ev´enement dans le seau pr´ec´edent est interpol´e avec le DR Pour la deuxi`eme technique

- SWS, les intervalles de temps peuvent ˆetre de taille variable selon le temps d’attente duclient le plus lent

Dans de tels syst`emes, il est impossible d’avoir des inconsistances, car l’ordre des ´ev´nements g´en´er´es est conserv´e efficacement Par contre, ces techniques de synchronisation

e-ne r´esolvent pas la latence pour les jeux ´etant sensibles `a la latence (par exemple lesjeux de type FPS) Il n’y a aucun moyen pour garantir que le jeu avancera `a un rythmer´egulier et constant, ou assez vite pour les jeux interactifs De ce fait, ces m´ecanismes

ne conviennent pas aux jeux qui demandent des mises `a jour tr`es fr´equentes, une forteconsistance, sont tr`es sensibles `a la latence

2.3.2.3 Time Warp Synchronization (TWS) et Trailing State Synchronization (TSS)

Ces m´ecanismes ex´ecutent les ´ev´enements au fur et `a mesure de leur apparition [13, 16],

mˆeme si un ´ev´enement ant´erieur aurait pu arriver Ils effectuent des retours en arri`ere pourr´eparer les inconsistances n´ecessaires

Dans TWS, l’´etat de tous les objets est sauvegard´e `a chaque intervalle fix´e de tempsavant d’ex´ecution d’un ´ev´enement En cas de retour en arri`ere (une contradiction d´etec-t´ee), tous les ´ev´enements entre la sauvegarde et le moment d’ex´ecution sont re-ex´ecut´es.Cependant, dans cette technique de synchronisation, comme un point de contrˆole (check-point [16]) est n´ecessaire pour chaque message, une m´emoire ´enorme est exig´ee Par cons´e-quent, cette technique n’est pas pratique

Fig 2.3 – L’ex´ ecution du remorquage d’´ etat de synchronisation dans TSS (Quake)

L’algorithme TSS est impl´ement´e dans Quake [4, 13] illustr´e sur figure 2.3 L’´etatglobal du jeu est parall`element ex´ecut´e par les remorquages d’´etat (trailing state) avec lesretards diff´erents Par exemple, `a l’instant t, autre que l’´etat actuel c’est celui qui est sur

le point d’ex´ecuter ; il y a un remorquage d’´etat qui ex´ecute la simulation `a l’instant t

-d1, et le deuxi`eme remorquage `a l’instant t - d2, etc Dans le cas d’inconsistance d´etect´ee,l’algorithme copie alors un des remorquages pour re-ex´ecuter.

2.4 Les plates-formes existantes

Cette section s’attache donc `a rapporter quelques intergiciels existants pour les jeuxmassivement multijoueurs

Continuum [5, 6] est une pi`ece essentielle du projet europ´een baptis´e Ping, dont lebut est de fournir une infrastructure d´edi´ee aux jeux vid´eo en r´eseau, capable de faireinteragir en temps r´eel des milliers de joueurs dispers´es `a travers le monde

Continuum vise `a la construction d’un monde virtuel sur Internet Un monde virtuelcontient un ensemble d’objets virtuels, appel´es entit´es, se situant dans le monde Unr´eplica est conceptuellement une reproduction d’une entit´e unique Eventuellement, lasimulation de ce monde virtuel est partiellement (globalement si n´ecessaire) repr´esent´eedans la machine d’un client, appel´e espace de simulation, par les r´eplicas des entit´esparticipant `a ce monde Une entit´e sera reproduite dans un espace de simulation si elle ainfluence sur d’autres objets dans cet espace Parmi les r´eplicas d’une entit´e, on distingue

le r´eplicas maˆıtre (master replica), ce qui peut ˆetre compris comme l’objet lui-mˆeme, lesautres sont les copies de l’objet Le r´eplica maˆıtre communique avec les autre en observantune politique pr´ed´etermin´ee de consistance (m´ecanisme de communication)

Les espaces de simulation du syst`eme se connectent les uns aux autres au moyendes canaux de communication et de mani`ere synchronis´ee Chacun d’entre eux est donccapable de calculer les interactions entre des entit´es

Architecture de plate-forme

Continuum est organis´e en couche, la fronti`ere entre ces couches est bien claire.Chaque couche se distingue par ses politiques et m´ecanismes et peut ˆetre ´etendue pours’adapter aux besoins des applications Le noyau d´ecrit un ensemble de composants abs-traits, dont chacun est visible des autres seulement par ses interfaces

Les communications entre les r´eplicas repr´esentant un objet sont effectu´ees par les

´ev´enements Une fois qu’un ´ev´enement est engendr´e, il est dat´e (pourrait ult´erieurement

ˆetre utilis´e par des m´ecanismes de synchronisation impl´ement´es dans l’application) Lesalgorithmes de synchronisation peuvent ˆetre int´egr´es `a plate-forme facilement, en fonctiondes caract´eristiques de l’application

infor-Gestion d’objets g`ere la correction des manipulations des entit´es r´

eplica-tives (book-keeping, cycle de vie, et ramasse miettes)Gestion d’´ev´enements le service de synchronisation (causalit´e en ordre, buffe-

ring, timestamp)Gestion d’Aura (Aura ma-

nagement)

responsable de filtrage des ´ev´enements selon le mod`ele

de r´eplication C’est cette couche qui route les ´ev´ments qui circulent par le r´eseau

ene-Groupe de communication fournit divers services de communication

Supporte de r´eseau int´egration des protocoles r´eseau

Fig 2.4 – L’architecture en couche de Continuum.

2.4.2 TERRAPLAY

TerraPlay [18] est une plate-forme qui a pour but de fournir une solution de hautequalit´e pour les d´eveloppeurs de jeux en temps r´eels, en r´eseaux fixe ainsi qu’en r´eseauxmobiles Le syst`eme se compose d’un faisceau de serveurs, qui sont charg´es de g´erer

et synchroniser les jeux Ils ne sont pas un centre pour distribuer les donn´ees tempsr´eels du jeu Le syst`eme TerraPlay s’occupe de toutes les copies et les multicast desdonn´ees du jeu Les d´eveloppeurs, qui voudraient construire leurs jeux sur cette plate-forme pour b´en´eficier des services de communications, devraient d´evelopper deux typesd’applications :(( lobby serveur )) et (( application d’utilisateur ))

Fig 2.5 – Les composants dans un jeu construit sur TerraPlay

Lobby serveur est utilis´e par les joueurs pour d´efinir les param`etres d’une session dujeu, pour authentification, la recherche des comp´etiteurs en ligne, et le d´emarrage

du jeu

Application d’utilisateur une instance de jeu sur la machine de joueur

Les applications de jeu interagissent avec les APIs r´eseau de TerraPlay, qui fontpartie du syst`eme TerraPlay mais r´esident sur les machines des clients

Une session du jeu est typiquement commenc´ee depuis le lobby serveur Les joueursacc`edent au lobby serveur pour recevoir les informations n´ecessaires pour qu’ils puissentrejoindre une session du jeu Ce sont :

– l’adresse de r´eseau de GAS (Game Access Server )

– le num´ero de port sur le serveur GAS

– le mot de passe

Fig 2.6 – Une architecture typique d’un jeu sur TerraPlay

Fig 2.7 – La communication dans syst` eme TerraPlay

Pour la communication entre les clients, TerraPlay fournit trois m´ecanismes rents : stream object, basic object, et message pour l’envoi des mises `a jours Lesdeux premiers m´ecanismes, stream object et basic object, sont tr`es similaire du mod`elepublisher/subscriber (respectivement bas´e sur sujet, et bas´e sur contenu)

diff´e-Les mises `a jour ne sont envoy´ees qu’aux clients qui voudraient les recevoir, et pourrecevoir ces informations, ils doivent s’y inscrire explicitement Les messages sont utilis´espour l’envoi des informations `a un joueur ou bien un groupe de joueurs d´etermin´es (avecdes adresses de destinataires bien indiqu´ese) Les informations envoy´ees sont priv´ees etsecr`etes Les mises `a jours envoy´ees par stream object peuvent ˆetre dat´es en utilisant leservice de temps du syst`eme Cependant, dans les deux modes stream ou basic object,seulement le dernier mises `a jour est prise en compte.

2.4.3 BUTTERFLY

ButterFly [19] est un environnement virtuel r´eseau de type client-serveur avec tiple serveurs qui emploie la technologie de grille2 (grid technology) Cette plate-formesupporte les jeux massivement multijoueurs et temps r´eels Elle fournit ´egalement unesuite compl`ete de logiciels pour aider les d´eveloppeurs des jeux `a d´evelopper, tester, op´e-rer, et g´erer

mul-Dans ButterFly, on divise l’espace virtuel en multiples r´egions Chaque r´egion estassign´ee `a un serveur Les serveurs sont totalement (( maill´es )), c’est-`a-dire que chacunest connect´e `a tous les autres dans le syst`eme par des fibres optiques `a haute vitesse Plusd’un million de participants peuvent jouer simultan´ement

Il y a deux faisceau de serveurs dans ButterFly compos´es de 50 eServer xSeries deIBM plac´es `a IBM Sterling, VA et Los Angeles, avec quatre cat´egories (bas´e sur leur rˆole

`

a l’int´erieur de la grille)

– Serveur de jeu (Game Server) - la plupart des serveurs dans chaque faisceau sontserveurs de jeu Ils sont g´en´eralement responsables d’ex´ecuter des jeux dans la grille.Leurs fonctions principales incluent la m´ediation du jeu, imposant les r`egles dejeu stock´ees sur des serveurs de base de donn´ees (ci-dessous) et commandant desinteractions avec d’autres serveurs de jeu Ces serveurs fonctionnent sur le mat´erielLinux-bas´e xSeries x330

– Serveur d’acc`es (Gateway servers) - fonctionnant aussi sur xSeries x330, ils sontresponsables de relier des joueurs (c.-`a-d., clients) aux serveurs de jeu Les serveurs

de passage effectuent ´egalement des traductions de protocole et conduisent des cordements de joueur aux serveurs de jeu

rac-– Les contrˆoleurs de d´emon (Daemon controllers) : sont des serveurs d’intelligenceartificielle (fonctionnant sur le mat´eriel de xSeries x330) dont la fonction est decommander des personnages de non-joueur et d’autres ´el´ements du jeu, pas directe-ment command´es par des actions des joueurs

– Les serveurs de bases de donn´ees (Database servers) - sont responsables de stocker

2 Une grille est un syst` eme (un infrastructure des mat´ eriels et des logiciels) de type parall` ele et r´ eparti qui permet le partage, le choix, et l’agr´ egation des ressources (( autonomes )) de mani`ere dynamique et g´ eographiquement distribu´ ees au temps d’ex´ ecution selon leur disponibilit´ e, possibilit´ es, performances, coˆ ut, et les demandes du qualit´ e-de-service des utilisateurs.

Fig 2.8 – Architecture de ButterFly

toute l’information (la physique, la g´eom´etrie, les r`egles du jeu, etc.) n´ecessaire pourmaintenir la persistance dans le monde Ces bases de donn´ees, log´ees sur les serveursmont´es sur les xSeries x232, maintiennent ´egalement la comptabilit´e et les donn´eesd’authentification et fournissent l’interface aux fonctions de soutien de facturation.

2.5 Conclusion

Avant qu’un jeu soit publi´e, il y de nombreux de travaux `a accomplir, surtout pourles jeux massivement multijoueurs en ligne Par contre, pour qu’un jeu puisse se rendremaˆıtre du march´e, le temps de d´eveloppement doit ˆetre le plus court possible Pour cetteraison il apparaˆıt sur le march´e des plates-formes visant `a aider les d´eveloppements de cetype d’application En utilisant les suites des logiciels robustes sur lesquels ses jeux sontconstruits, les temps de d´eveloppement sont abr´eg´es, car les d´eveloppeurs se concentrentsur les jeux, et non pas sur la communication r´eseau ou bien les mod`eles physiques parexemple Ce stage se d´eroule dans le cadre de projet M´ega, qui a pour but de construireune plate-forme pour les jeux massivement multijoueurs et en r´eseau mobile

Les travaux de ce stage sur (( Les abstractions de communication dans les jeux enr´eseau mobile )), ont commenc´e il y a deux mois Nous nous concentrons sur l’aspectcommunication r´eseau, dont les aspects importants sont l’efficacit´e, la robustesse, la la-tence faible, et le passage `a l’´echelle du m´ecanisme de communication du syst`eme dans lecontexte des r´eseaux mobiles Ce chapitre vise `a donner une vue g´en´erale sur les obstaclesqui empˆechent les jeux en ligne d’atteindre les succ`es comme les jeux sur une machine,

ou un r´eseau local Un des d´efis majeurs de ce type d’application a bien ´et´e reconnu ;c’est la latence de communication Les effets issus de la latence peuvent ˆetre efficacementr´eduit d’une part au moyen de m´ecanismes de synchronisation impl´ement´es dans syst`emepr´esent´es ci-dessus, et d’autre part, par une strat´egie intelligente de communication C’est

la deuxi`eme approche dont le travail du stage fait partie

Un m´ecanisme de communication est intelligent et efficace s’il n’est pas superflu enterme de montant d’information voyageant sur le r´eseau Par exemple, il est clairementinutile d’envoyer un ´ev´enement `a un objet si ce dernier ne subit aucune influence3 decet ´ev´enement La bande passante du r´eseau peut ˆetre sauvegard´ee en communiquantdes donn´ees seulement aux objets qu’il influence Il faut noter que le choix de l’informa-tion `a envoyer est le travail des concepteurs du jeu Ce que fournit l’intergiciel sont desm´ecanismes de synchronisation et de communication r´eseau efficace (latence faible, faut-tol´erance, etc) Le mod`ele de communication publish/subscribe est abondamment ´etudi´edans ces r´ecentes ann´ees, et a ´et´e impl´ement´e dans quelques plates-formes Dans la suite

de ce stage nous allons approfondir ce mod`ele de communication qui nous semble celuiqui est le plus convenable pour ces types d’application

3 On appelle la r´ egion d’influence d’un objet un cercle dont le centre est la position de l’objet, et le largeur du rayon est la distance que l’objet peut avoir des influences sur d’autres

Environnements mobiles et Mod`ele de

Communication

Actuellement, dans la plupart des cas de jeux massivement multijoueur, la cation consomme beaucoup de ressources r´eseau Le paradigme de communication dansces applications est de type client/serveur, o`u la communication a lieu typiquement entredeux entit´es, le client et le serveur Les clients du jeu partagent une unique instance dumonde virtuel au moyen du serveur, qui leur passe, apr`es les avoir trait´e, tous les ´ev´ene-ments issus de tous les clients Or, un participant n’a besoin de recevoir que les ´ev´enementsqui lui sont pertinents Par exemple, seulement ceux issus des clients qui peuvent avoirune influence sur lui ; ou probablement ˆetre influenc´es par ses actions Par cons´equent, ilsdoivent eux-mˆemes ˆetre responsables de filtrer les ´ev´enements pertinents qui leur arrivent.Ceci augmente consid´erablement la latence de r´eseau A cause de ces limitations, ce pa-radigme de communication ne convient plus `a la construction des syst`emes distribu´es `agrande ´echelle, particuli`erement pour les jeux massivement multijouers en r´eseau mobile.Dans ces derni`eres ann´ees, le syst`eme publish/subscribe attire beacoup d’attentiondans la litt´erature [31, 33, 34], et aussi dans l’industrie [43, 42, 44] Un syst`eme pu-blish/subscribe route dynamiquement et d´elivre les ´ev´enements des sources aux utilisa-teurs int´eress´es Il est extrˆemement utile lorsqu’il n’est pas pr´evisible `a l’avance qui abesoin de quelles informations Sa nature permet d’´eviter les limitations rencontr´ees dans

communi-un syst`eme client/serveur (( traditionnel )) En premier pas, [3, 23] ont impl´ement´e lemod`ele publish/subscribe pour les jeux multijoueur, mais limite `a utiliser dans un r´eseaufilaire plutˆot que mobile

Dans ce chapitre, nous pr´esentons d’abord des caract´eristiques des environnementsmobiles Ensuite nous nous concentrons sur les concepts de publish/subscribe

26

3.1 Infrastructure Mobile

3.1.1 R´eseau sans fils

Un r´eseau sans fils, (en anglais wireless network) est un r´eseau t´el´ephonique ou matique qui utilisent des ondes radio-´electriques (radio et infrarouges) comme porteurs designaux (correspondre `a la couche physique dans le mod`ele OSI), au lieu et `a la place des

infor-cˆables habituels Grˆace aux technologie sans fils, les utilisateurs ont possibilit´e de resterconnect´es tout en se d´epla¸cant dans un p´erim`etre g´eographique offrant une connectivit´e(appel´e zone de couverture), c’est la raison pour laquelle le mot(( mobilit´e )) est ´egalementutilis´e dans le contexte de la t´el´ecommunication sans fils

Par rapport aux r´eseaux filaires (( traditionnels )), les r´eseaux sans fils permettent

de relier tr`es facilement des ´equipements distants d’une dizaine de m`etres `a quelqueskilom`etres De plus, comme ´etant lib´er´e de toutes les connectivit´es par cˆables, l’installationd’un tel r´eseau est beaucoup plus simple `a mettre en place On distingue habituellementplusieurs cat´egories de r´eseaux sans fils, selon la zone de couverture, les plus connues sont :– WLAN (Wireless Local Area Network ) Les r´eseaux WLANs sont les r´eseaux locauxsans fils qui utilisent les ondes radios comme porteur des signaux : les liens avec lesutilisateurs sont sans fils, ils donnent des connections r´eseaux `a tous les utilisateursdans un bˆatiment ou sur un campus Le r´eseau f´ed´erateur emploie habituellementdes cˆables `a haut d´ebit Il existe actuellement sur le march´e plusieurs technologiesconcurrentes, Wi-fi (ou IEEE 802.11x), HomeRF (Home Radio Frequency) parexemple

– WPAN (Wireless Personal Area Network ) Le r´eseau personnel sans fils WPANconcerne les r´eseaux sans fils d’une faible port´ee (de l’ordre de quelques dizainesm`etres) Les techniques employ´es pour ce type de r´eseaux sans fils sont : Blue-tooth, IEEE 802.15 et ZigBee (aussi sous le nom IEEE 802.15.4), et les liaisonsinfrarouges

– WWAN (Wireless Wide Area Network ), le r´eseau ´etendu sans fils WWAN est unr´eseau t´el´ephonique mobile, ´egalement connu sous le nom de r´eseau cellulaire mobile

Il s’agit des r´eseaux sans fils les plus r´epandus puisque tous les t´el´ephones mobilessont connect´es `a un r´eseau ´etendu sans fils Les principales technologies sont : GSM(Global System for Mobile Communication ou en fran¸cais Groupe Sp´ecial Mobile),GPRS (General Packet Radio Service), UMTS (Universal Mobile Telecommuni-cation System), etc

3.1.2 Architecture des r´eseaux WLANs

La norme IEEE 802.11 (ISO/IEC 8802-11) [39] s’attache `a d´efinir les couches basses(physique et liaison de donn´ees) du mod`ele OSI pour une liaison sans fil utilisant desondes ´electromagn´etiques Le nom WiFi (pour Wireless Fidelity, parfois not´ee Wi-Fi) a

initialement ´et´e utilis´e par la Weca (Wireless Ethernet Compatibility Alliance [40]) pour

sa certification Par abus de langage (et pour des raisons de marketing) le nom de la norme

se confond aujourd’hui avec le nom de la certification Ainsi un r´eseau Wifi est en r´ealit´e

un r´eseau r´epondant `a la norme 802.11

Le standard 802.11 d´efinit deux modes op´eratoires : (1) le mode `a point d’acc`es et (2)

le mode ad hoc

– Le mode `a point d’acc`es : Dans ce mode, les clients sans fil, appel´es les unit´esmobiles, ou hˆotes mobiles sont munies d’interfaces de communication sans fils, quileur permettent de se connecter `a un point d’acc`es (ou une station de base, no-t´ee BS pour Basic Station en anglais) pour former un ensemble de service de base(BSS : Basic Service Set) constituant une cellule Plusieurs points d’acc`es peuventˆ

etre interconnect´es entre eux `a travers un r´eseau filaire ou mˆeme sans fils, mais g´en´ralement fiable et d’un d´ebit ´elev´e afin de constituer un ensemble de service ´etendu(ESS pour Extented Service Set) Bien que des recouvrements entre les cellules ad-jacentes soient possibles, les unit´es mobiles ne peuvent se connecter, `a un instantdonn´e, qu’`a une seule station de base Grˆace au protocole de Handoff au cours de

e-la mobilit´e, les unit´es mobiles restent toutes connect´ees en se d´epla¸cant librementd’une station de base `a une autre au sein de l’ESS Cette caract´eristique permettantaux unit´es mobiles de (( passer de fa¸con transparente )) d’un point d’acc`es `a unautre est appel´e itin´erance (en anglais roaming)

– En mode ad-hoc les machines clients se connectent les unes aux autres afin deconstituer un r´eseau point `a point Il n’existe aucun point d’acc`es, mais ce sont lesunit´es mobiles qui jouent le rˆole de client et le rˆole de point d’acc`es en mˆeme temps.Pour cela, chaque nœud est muni d’un adaptateur de communication sans fils, mais

´

etant capables de router les paquets qui lui arrivent

3.1.3 Mod`ele de calculs mobiles

La figure 3.1 montre l’architecture g´en´erale d’une plate-forme mobile largement admise[27] Le mod`ele consiste en des composants mobiles et stationnaires, ayant l’architectureplutˆot de type distribu´ee Les ordinateurs, les hˆotes fixes, et les stations de bases sontinterconnect´ees `a travers un r´eseau filaire fiable et d’un d´ebit ´elev´e Seules les unit´esmobiles sont les composants mobiles

Les hˆotes fixes dans ce mod`ele sont des ordinateurs, qui ne sont pas ´equip´es pour ˆetrecapables de se connecter aux unit´es mobiles, mais peuvent ˆetre configur´es pour le faire.Les BSs communiquent avec les unit´es mobiles dans une cellule pour supporter l’acc`es desdonn´ees La discipline mobile exige donc que le mouvement des unit´es mobiles soit sansrestriction dans le domaine g´eographique de mobilit´e (mouvement d’inter-cellule)

Fig 3.1 – Mod` ele de calcul mobile

3.1.4 Caract´eristiques des environnements mobiles

Les caract´eristiques sp´ecifiques dans un r´eseau sans fils doivent ˆetre prises en comptepar les concepteurs des applications Les applications doivent ˆetre flexibles et s’adapteraux conditions d’ex´ecution courantes

– Limitation des ressources : actuellement, les dispositifs mobiles sont ´equip´es tativement des ressources (la puissance du processeur, la taille de la m´emoire vive(RAM), la capacit´e de stockage, et la limitation de l’automobile) La disponibilit´e

limi-et la qualit´e des ressources varient au cours de l’utilisation Les applications doiventdonc ˆetre inform´es de ce changement, pour adapter leurs comportements pour utili-ser plus ou moins de ressources Une application pourrait, par exemple, passer d’unmode graphique `a un mode textuel pour ´economiser la batterie D’autre part, due

`

a la mobilit´e et aux interf´erences, la bande passante dans un r´eseau sans fils esttr`es variable et reste inf´erieurement limit´ee aux d´ebits dans les r´eseaux filaires Afind’assurer une bonne qualit´e de service, il faut que les applications s’adaptent dyna-miquement aux caract´eristiques des r´eseaux sans fils R´eduire le volume de donn´ees(d´egradation de la qualit´e, taux de compression, cadence d’images de la vid´eo) est

un exemple de l’adaptation dynamique aux capacit´es de r´eseaux

– Connexion et d´econnexion tr`es fr´equentes : pour sauvegarder la batterie, une unit´emobile peut s’´eteindre ou se d´econnecter souvent du r´eseau pour une long p´eriode

de temps Ces d´econnexions fr´equentes doivent ˆetre consid´er´ees, au niveau cation, comme un mode de fonctionnement normal

d’appli-3.2 Le mod`ele Publish/Subscribe

3.2.1 Les ´el´ements dans un syst`eme publish/subscribe

Un syst`eme publish/subscribe se compose : (1) d’un service de notification (NS pournotification service en anglais) qui consiste en un ou plusieurs serveurs d’´ev´enement1, et(2) d’un ensemble de clients qui sont d´ecoupl´es par le service de notification selon leur rˆole :les publishers ou les subscribers Les publishers publient les ´ev´enements qu’ils produisent

au NS De leur cˆot´e, les subscribers fournissent au NS lors de sa souscription un patron

de filtre, ou simplement un filtre `A partir de ce moment jusqu’`a leur d´esabonnement,ils re¸coivent toutes les notification des nouveaux ´ev´enements qui satisfont aux conditionsexprim´ees dans le filtre Un client peut `a la fois ˆetre un producteur et un consommateurd’´ev´enements

L’algorithme pour d´eterminer si un ´ev´enement s’accorde ou non `a un filtre est impl´ment´e dans la fonction de correspondance (matching function) Le service de notificationg`ere et d´elivre les ´ev´enements re¸cus au moyen de la fonction de correspondance, et del’algorithme de routage Dans litt´erature, le (( m´ecanisme de s´election de notification ))[31] fait r´ef´erence `a l’application de la fonction de correspondance et de l’algorithme deroutage pour router dynamiquement les ´ev´enements Une publication d’´ev´enement issued’un producteur d´eclenche ensuite le m´ecanisme de s´election

e-Fig 3.2 – Mod` ele Publish/Subscribe de base

La figure 3.2 montre le mod`ele de base d’un syst`eme publish/subscribe Le serviced’´ev´enement est charg´e de g´erer les souscriptions des subscribers Il est responsable ded´elivrer correctement les ´ev´enements aupr`es seulement des consommateurs qui veulentvraiment les recevoir Quelque soit l’impl´ementation d’une variante de publish/subscribe,

1 Dans la litt´ erature, et aussi dans ce rapport, on rencontre diff´ erents noms utilis´ es de fa¸ con m´ elang´ ee Entre autres, les plus populaires sont le service d’´ ev´ enement, ou bien les courtiers et les r´ epartiteurs d’´ ev´ enement (respectivement Event Broker et Event Dispatcher)

elle doit fournir au moins trois primitives : subscribe(), unsubscribe(), publish().L’op´eration subscribe() sur le service d’´ev´enement est appel´ee par les subscribers pourenregistrer leurs int´erˆets L’op´eration publish() est invoqu´ee par les publishers quand

il y a un nouvel ´ev´enement apparaˆıt Du cˆot´e des subscribers, ils doivent impl´ementerl’op´eration notify(), pour que le service d’´ev´enement puisse notifier l’apparition d’unnouveau ´ev´enement correspondant

Ce mod`ele de communication et de coordination entre les participants repr´esente descaract´eristiques tr`es int´eressantes :

– Premi`erement, les deux parties interagissant n’ont pas besoin de se connaˆıtre pace d’interaction est d´ecoupl´e par le service d’´ev´enement qui est interpos´e Ilsuffit donc de sp´ecifier au service d’´ev´enement ce qui int´eressent les subsribers.Ceci facilite la flexibilit´e et l’extensibilit´e du syst`eme car les nouveaux consomma-teurs/producteurs d’´ev´enements peuvent ˆetre ajout´es au syst`eme, ou retir´es facile-ment, sans aucune influence sur les autres

L’es-Fig 3.3 – d´ ecoupage de l’espace d’interaction dans un syst` eme Publish/Subscribe

– Deuxi`emement, la communication dans le syst`eme est de type asynchrone, ce qui

´

elimine les d´esavantages rencontr´es dans un syst`eme de communication synchrone(comme dans un syst`eme client/serveur par exemple, la communication synchroneimplique que le client doit ˆetre bloqu´e jusqu’`a l’arriv´e de la r´eponse du serveur)

Fig 3.4 – d´ ecoupage d’´ ecoulement

– Troisi`emement, il n’est pas n´ecessaire que les producteurs et les consommateurssoient disponibles en mˆeme temps Apr`es avoir sp´ecifi´e ses int´erˆets sur les ´ev´ene-ments aupr`es de service d’´ev´enement, un subscriber va recevoir tous les nouveaux

´

ev´enements correspondants en provenance des publishers, y compris naturellementles publishers qui rejoignent le syst`eme apr`es la souscription

Fig 3.5 – d´ ecoupage de temps

– Finalement, le publish/subscribe refl`ete directement le comportement intrins`equedes applications bas´e sur ´ev´enement parce que la communication est lanc´ee pardes producteurs d’´ev´enement Cette derni`ere caract´eristique rend ce mod`ele un bonchoix pour les syst`eme bas´e sur l’´ev´enement

En enlevant toutes les d´ependances entre les participants d’interaction dans le syst`eme,

le mod`ele publish/subscribe devient tr`es convenable, et donc le premier choix pour les t`emes de notification d’´ev´enements `a grande ´echelle Pour mettre en œuvre la notion dumod`ele publish/subscribe dans un syst`eme r´eel, il nous reste des d´efis int´eressants `a ´etu-dier, dont un aspect fondamental est l’expression de choix de notification, c.-`a-d., commentles consommateurs indiquent des souscriptions Le choix du m´ecanisme de souscriptionest peut-ˆetre le plus important `a faire en d´eveloppant un service de notification

sys-3.2.2 Mod`ele de souscription

L’expression du choix de notification est cruciale pour la flexibilit´e d’un service de fication Dans les syst`emes `a grande ´echelle, l’expression du choix de notification doit ˆetresoigneusement choisie car l’expression et le passage `a l’´echelle sont interd´ependants D’unepart, une expression insuffisante peut mener aux souscriptions inutiles, et par cons´equence,sature le r´eseau et soulevant le besoin de filtres additionnels Dans le cas le pire, quand

noti-le m´ecanisme de s´election de notification ne peut pas arriver `a analyser une expression,toutes les notifications peuvent ˆetre livr´ees et le choix est impos´e aupr`es du consomma-teur D’autre part, les r´ealisations extensibles des mod`eles de filtre plus expressifs exigentdes strat´egies plus complexes de la livraison Dans la suite, trois m´ecanismes communs dechoix de notification sont d´ecrits : bas´e sur le sujet (subject-based), bas´e sur le contenu(content-based) et bas´e sur le type (type-based) respectivement [32, 31, 34]

3.2.2.1 Mod`ele bas´e sur sujet

Au niveau abstraction, les ´ev´enements, en provenance des publishers, sont transmisvers les subscribers par les canaux virtuels Chaque canal est repr´esente par un mot-cl´e(sujet), Les publishers publient les ´ev´enements en les associant `a un canal Les subscriberss’inscrivent pour pouvoir ˆetre attir´es l’intention sur l’apparition de nouveaux ´ev´enements.Dans la litt´erature, les notions de canal, sujet, et groupe sont souvent m´elang´ees Lanotion de groupe est utilis´ee dans le contexte (( groupe de communication )) [35] En

s’inscrivant au groupe, un subscriber devient le membre de ce groupe, et la publicationd’un ´ev´enement vers un groupe diffuse cet ´ev´enement `a tous les membres de ce groupe.L’algorithme de correspondance consite donc simplement `a g´erer ces groupes.

L’avantage de ce mode de souscription est que l’impl´ementation est plus simple que

le mod`ele bas´e sur contenu (voir plus tard) Par contre, l’expression de la souscriptionest limit´ee par le choix de canaux parmi ceux qui existent a priori Subs´equemment, les

´ev´enements sont limitativement classifi´es selon seulement ces canaux Moins de canauxexistent, plus il est difficile d’exprimer les souscriptions Les canaux sont peu flexibles, car

si le sujet assign´e `a un canal est chang´e, les deux publisher et subscriber doivent changer

´egalement

En pratique, on ´etend l’expression de souscription en fournissant une organisation hi´rarchique au lieu d’un ensemble de sujets simples Un sujet B peut ˆetre d´efinit comme unsous-sujet d’un sujet A existant De cette fa¸con, on arrive `a construire l’ensemble de sujetsous forme d’un arbre2 Donc, une notification qui s’accorde avec A satisfait B naturelle-ment La souplesse de souscription peut ˆetre augment´ee si le syst`eme fournit les op´erations

e-en plus dans l’impl´ementation, comme par exemple les caract`eres de remplacement, pourqu’un subscriber puisse s’inscrire `a plus d’un sujet dans l’arbre de sujet Malgr´e cetteextension, une restriction existe encore est que l’on ne peut classifier les ´ev´enements qu’enespaces `a une dimension Parce que l’utilisation de multiple dimension m`ene rapidement

`

a une exposition de la taille de l’arbre, `a cause des r´ep´etitions des sous-arbres [31] lement, les deux producteur et consommateur ne sont pas totalement d´ecoupl´es car c’est

Fina-le producteur qui d´ecide les canaux dans lesquels il publie les ´ev´enements

3.2.2.2 Mod`ele bas´e sur contenu

Ce deuxi`eme mod`ele de souscription rem´edie aux inconv´enients du premier en duisant un sch´ema de souscription bas´e sur les propri´et´es des notifications consid´er´ees.Les ´ev´enements ne sont pas classifi´es selon quelques crit`eres externes pr´ed´efinis (comme

intro-le nom de sujet, par exempintro-le), mais selon intro-les propri´et´es des ´ev´enements eux-mˆemes Cespropri´et´es peuvent ˆetre les attributs internes, ou m´eta-donn´ees associ´es `a un ´ev´enement

On voit que le mod`ele pr´ec´edemment pr´esent´e est un cas particulier de ce mod`ele desouscription

Dans les syst`emes publish/subscribe bas´es sur contenu, les consommateurs exprimentleurs attentions en sp´ecifiant les conditions sur les contenus des ´ev´enements qu’ils vou-draient recevoir En g´en´eral, une souscription a la forme d’une requˆete, qui se composedes paires nom-valeur des propri´et´es (des ´ev´enements) comme des op´erandes, et ´eventuel-lement d’autres op´erateurs logiques (and, or, not, etc.), les combinant pour former dessouscriptions plus sophistiqu´ees L’argument `a l’entr´ee de l’op´eration subscribe(), dans

ce cas, est donc habituellement de type (( string )) (chaˆıne de caract`eres) P.Th Eugster

et P Felber [32] ´enum`erent deux autres moyens pour repr´esenter un patron de filtre :

2 La question se pose alors c’est qui est responsable de d´ efinir l’arbre ?