TECHNIQUES DE FILTRAGE EN ENVIRONNEMENT VIRTUEL DISTRIBUE

Transcription

1 Institut de Recherche en Informatique de Toulouse Laboratoire de Synthèse d Images et Réalité Virtuelle DEA Informatique de l Image et du Langage TECHNIQUES DE FILTRAGE EN ENVIRONNEMENT VIRTUEL DISTRIBUE Rapport de DEA DIRECTEUR DE RECHERCHE : J.P JESSEL ENCADRANT : P. TORGUET David PHAM Mots clefs : environnements virtuels distribués, HLA, multicast, sockets, filtrage. Résumé : La limitation de la bande passante de l infrastructure du système nécessite l utilisation de techniques de filtrage pour optimiser le transfert des messages circulant sur le réseau. Cet article présente un état de l art sur les techniques de filtrage existantes. Une telle optimisation, utilisant le dead-reckoning et le filtrage par régions est implémentée et discutée. Abstract : Because of the bandwidth limits of the runtime infrastructure system. It is necessary to use network-filtering methods in order to optimize the transfer of messages through the network. This research study presents a state of the art on network-filtering techniques that currently exist. An optimization using dead-reckoning and regions based filtering is implemented and discussed. Keywords: distributed virtual environments, HLA, multicasting, sockets, network-filtering. 1

2 Remerciements Je tiens à remercier le directeur de recherche Luis Fariñas del Cerro pour avoir bien voulu m'accueillir à l'irit. Je remercie M. le professeur R. CAUBET pour m'avoir accepté dans son équipe. Je remercie également P. TORGUET pour son encadrement remarquable et irréprochable et l'aide permanente qu'il a pu m'apporter ainsi que J.P. JESSEL. Enfin, je tiens à remercier l'ensemble des membres de l'équipe pour leur disponibilité et leurs conseils éclairés. 2

3 Table des matières PREMIERE PARTIE : Etat de l art sur les environnements virtuels distribués et les méthodes de filtrage existantes 1. Environnements virtuels distribués 6 2. Différents systèmes d environnement virtuel distribué utilisant les protocoles multicast SIMNET DIS (DISTRIBUTED INTERACTIVE SIMULATION) 9 3. Architectures et topologie de distribution Totalement connecté Client / Groupe de serveurs Topologie à deux niveaux Approches du filtrage dans les environnements virtuels distribués Première approche Le filtrage selon NPSNET Le filtrage selon DIS Le filtrage selon HLA Le filtrage selon SPLINE Le filtrage selon MASSIVE Le filtrage selon WAVES Le filtrage selon VIPER Le filtrage selon DIVE 22 SECONDE PARTIE : Analyse des problèmes du filtrage et Implémentations 5. PRESENTATION D HLA METHODES ET IMPLEMENTATIONS DU FILTRAGE Dead-reckoning Implémentation Implémentation du filtrage basée sur des régions Services de communication Utilisation des sockets pour le filtrage Surcharge des méthodes de HLA CONCLUSION ET PERSPECTIVES 35 3

4 Table des illustrations FIGURE 1 SCHEMA GENERAL D'UN ENVIRONNEMENT VIRTUEL...6 FIGURE 2 PROJET SIMNET...8 FIGURE 3 DISTRIBUTED INTERACTIVE SIMULATION (DIS)...9 FIGURE 4 ARCHITECTURE TOTALEMENT CONNECTEE...11 FIGURE 5 ARCHITECTURE CLIENT/SERVEUR...12 FIGURE 6 ARCHITECTURE CLIENT/GROUP DES SERVEURS...12 FIGURE 7 RESEAU MULTICAST...13 FIGURE 8 TOPOLOGIE A DEUX NIVEAUX...14 FIGURE 9 GRILLE HEXAGONALE...16 FIGURE 10 ARCHITECTURE DE LA RTI...19 FIGURE 11 SCHEMA DE FONCTIONNEMENT DE LA RTI...24 FIGURE 12 EXEMPLE D ESPACE DE ROUTAGE...26 FIGURE 13 LA CLASSE TANKGHOST UTILISEE POUR IMPLEMENTER LE DEAD RECKONING HERITE DE LA CLASSE TANK...29 FIGURE 14 LE TANK LOCAL ET LE TANK FANTOME...29 FIGURE 15 DIVISION DU MNT EN CELLULES ET REGIONS D ECOUTE ET D ENVOI...31 FIGURE 16 REGION D ECOUTE (COLOREE EN VERT) DU TANK ET LA DIVISION DU MNT EN CELLULES FIGURE 17 PROCEDURES D ENVOI DES MESSAGES DANS LES REGIONS ABONNEES ET LA RECEPTION DES MESSAGES PROVENANT DES PARTICIPANTS INSCRITS DANS LA MEME REGION...32 FIGURE 18 SURCHARGE DES METHODES DE HLA

5 PREMIERE PARTIE Etat de l art sur les environnements virtuels distribués et les méthodes de filtrage existantes 5

6 1.Environnements virtuels distribués Le but de la Réalité virtuelle est de simuler un environnement réel, constitué d entités représentant des objets, agents, avatar, et d interagir sur cet environnement à l aide d un ordinateur et de périphériques associés. L intégration de la distribution dans cet environnement virtuel, ce que l on nomme les Environnements Virtuels Distribués, (nous parlerons indifféremment de «réalité virtuelle distribuée» et «d environnements virtuels distribués») permettant d étendre cette interaction à plusieurs participants géographiquement distants intervenant en même temps et/ou en temps réel sur ce même environnement. Le modèle d information qui décrit l environnement virtuel distribué est dupliqué sur les sites participant à son exécution. Pour maintenir la cohérence entre les parties dupliquées de ce modèle, il est nécessaire de diffuser à l ensemble des sites les actions issues d un site particulier. Utilisateur 1 Utilisateur 2 Utilisateur 3 Avatar 1 Avatar 2 Interactions Avatar 3 Interactions Objet 1 Objet 2 Objet 3 Objet 4 Monde virtuel Figure 1 Schéma général d'un environnement virtuel 6

7 Dans une simulation distribuée à grande échelle, avec des milliers de participants et d'objets, l'efficacité de transmission des données est une question primordiale, et c'est surtout à ce niveau qu'intervient le filtrage de données. Le but du filtrage est de limiter intelligemment les messages reçus (resp. envoyés) par des fédérés dans l'environnement distribué. De nombreuses techniques de filtrage utilisent des protocoles multicast. 2.Différents systèmes d environnement virtuel distribué utilisant les protocoles multicast Le protocole multicast [Eriksson, 1994], basé sur UDP/IP, permet de créer au niveau du réseau des groupes de communication. Ces groupes sont identifiés par des adresses qui leur sont réservés. Les messages envoyés à un tel groupe sont reçus par tous les membres abonnés au groupe. L abonnement et le désabonnement à un groupe multicast peut se faire à tout moment, le réseau se met à jour dynamiquement. Dans un réseau étendu, l information d abonnement des machines au groupe multicast est stockée par des routeurs multicast ou des machines spécifiques gérant un routage multicast logiciel. Ces routeurs sont structurés de manière hiérarchique. Lors d un abonnement ou d un désabonnement, la configuration des routeurs doit être mise à jour, ce qui crée un problème de latence pour ce type d opération. Cette latence d abonnement et désabonnement aux groupes multicast peut compromettre certains choix d utilisation des groupes multicast dans une stratégie de filtrage, surtout lorsque l existence de ces groupes est liée à des paramètres qui varient rapidement. Malgré ce problème, le multicast est très intéressant car, par rapport aux protocoles point à point (unicast) tels que TCP, il évite de dupliquer le même message s il a plusieurs destinataires. Par rapport à un protocole de diffusion (broadcast), il permet sur un réseau étendu de cibler exactement les destinataires et éviter ainsi les messages inutilement envoyés. Le multicast requiert cependant le support actif du réseau, et il n est pas encore implanté de manière efficace (d où les problèmes de latences évoqués plus haut). Par ailleurs, la gestion de la congestion, le contrôle de flux et la fiabilité sont des problèmes plus complexes dans le cas du multicast. L implantation du multicast n est généralement pas entièrement fiabilisée (des paquets peuvent se perdre). Il existe cependant plusieurs implantations de protocoles multicast qui tentent de permettre une meilleure gestion de la qualité de service, tels que : RMP, RMTP, LRMP. Le multicast est implanté de manière non fiable sur Internet sous la dénomination de MBone (Multicast Backbone). Le MBone relie les routeurs multicast de l Internet pour former un sous-réseau. En fait, le MBone est composé de plusieurs îlots de routeurs multicast qui sont reliés entre eux par un mécanisme de pontage : les paquets multicast sont contenus dans des paquets IP classiques afin de leur permettre de franchir les routeurs non multicast se trouvant entre ces îlots. Ainsi, le MBone cohabite de manière transparente avec les autres protocoles de l Internet. 7

8 L utilisation de techniques de multicast n est pas en soi la solution au problème de la montée en charge des systèmes de réalité virtuelle distribués. Le multicast peut être utilisé pour mettre en œuvre une stratégie de gestion des intérêts des participants, c est-à-dire, une stratégie d utilisation des groupes selon la connaissance que l on a des besoins des simulations participantes. Cela induit des choix architecturaux aux niveaux système et applicatif pour prendre en compte cette connaissance. Le multicast est typiquement utilisé en association avec de l information de type géographique sur l environnement virtuel : on met par exemple en œuvre une grille 2D dont les cellules correspondent à des groupes de communication ; ces groupes permettent de filtrer les messages selon la localisation géographique des entités qui les ont émis 2.1.SIMNET SIMNET (simulator networking) est un environnement militaire virtuel distribué [Calvin et al., 1993] initialement développé pour DARPA (Agence des projets de recherche avancés de défense). Le but du projet SIMNET est de développer un environnement en réseau à bas prix pour pouvoir entraîner des petites unités à se battre en équipe. Figure 2 Projet SIMNET On peut se connecter à SIMNET à partir de n importe quel point du réseau, en utilisant un simulateur comme point d entrée dans l environnement synthétisé. Une fois connecté, le participant peut interagir avec les autres utilisateurs déjà connectés. L architecture logicielle du réseau SIMNET possède trois composants de base : - Une architecture objet - événement, - Une notion de simulation d entités autonomes, et - L intégration d une technique prédictive appelée «dead-reckoning». L architecture objet - événement de SIMNET représente le monde comme une collection d objets et les interactions entre ces objets sont considérées comme une collection d événements. Les objets sont des véhicules, des systèmes d armement qui peuvent interagir à 8

9 travers le réseau et les événements sont simplement des messages permettant d indiquer des changements du monde ou pour décrire l état d un objet. La notion de simulation d entité autonome signifie qu un joueur (véhicule ou système d armement) connecté au réseau est responsable de la diffusion des messages ou des paquets, sur le réseau pour indiquer exactement son état actuel et que les destinataires doivent mettre à jour leur copie locale du monde à partir de ces données. Le fait que SIMNET n utilise pas de serveur central signifie qu une simple défaillance dans le système ne pourra pas arrêter la simulation en cours. De plus, il permet aux participants de rejoindre et de quitter la simulation à tout instant. Diffuser des changements d état sur le réseau signifie que la machine doit envoyer les paquets sur le réseau, toute fois, les objets doivent apporter une modification significative de leur état pour que les autres participants puissent tenir compte de ces changements. Diffuser l état actuel signifie aussi qu une machine doit fournir un message régulièrement, environ toutes les cinq secondes, pour permettre aux autres d être informés qu un objet particulier est toujours en vie ou connecté au système. L utilisation de techniques prédictives comme le «dead-reckoning» permet de réduire le trafic du réseau. Avec ces techniques, un participant fait tourner des simulations «fantômes» représentantes des entités distantes, si la distance (ex : distance euclidienne) séparant l entité locale et l entité fantôme est supérieure au seuil fixé alors une mise à jour est envoyée sur le réseau. Ces simulations sont ajustées lorsque leur erreur de prédiction devient trop importante. 2.2.DIS (DISTRIBUTED INTERACTIVE SIMULATION) DIS est destiné au départ à des missions à caractère militaire (reproduction de batailles, entraînement de troupes), mais s'y sont ensuite ajoutées des applications pour l'aviation Civile, les plans d'organisation de secours en cas de désastre naturel, etc. Dans D.I.S., le monde est modélisé comme un ensemble d'entités qui interagissent les unes avec les autres par le biais "d'événements ", qu'elles créent et qui peuvent être perçus par les autres entités. Au cœur de D.I.S., on trouve un ensemble de protocoles qui permettent d'envoyer des messages au sujet des entités et des événements sur un réseau reliant entre eux les " nœuds " de simulation, c'est à dire les plates-formes informatiques ou réelles responsables de l'entretien des entités des Mondes Virtuels. Figure 3 Distributed Interactive Simulation (DIS) 9

10 L architecture logicielle du réseau DIS est un descendant direct de SIMNET mais possède des paquets qui sont plus standardisés que ceux de SIMNET. Elle est constituée également de trois composants de base : - Une architecture objet - événement, - Une notion de simulation partagée, - L intégration du «dead-reckoning». Les participants interagissent entre eux grâce à un certain nombre de PDU (Protocol Data Unit), qui sont des messages standards. Par rapport à SIMNET, DIS essaie de standardiser le format des messages afin d améliorer l interopérabilité entre les simulateurs de différents milieux. Le standard DIS (IEEE1278) est défini par 27 PDU différents, mais seulement quatre d entre eux (Entity State, Fire, Detonation, Collision) sont utilisés par les entités pour interagir avec l environnement virtuel. Les protocoles multicast sont beaucoup utilisés par DIS afin d accroître l extensibilité des simulations distribuées. Même si le dead-reckoning est utilisé dans DIS, il reste encore toujours trop de messages inutiles circulant sur le réseau. La notion de gestion de l intérêt des participants est alors devenue primordiale. Dans le meilleur des cas, gérer l intérêt d un participant, c est véhiculer uniquement des messages strictement nécessaires à son bon fonctionnement. En utilisant des protocoles de communication de groupe. 10

11 3.Architectures et topologie de distribution Il existe différentes manières de se connecter à l environnement virtuel distribué. La connexion requiert la mise en œuvre de liaisons physiques adéquates et l utilisation de protocoles de communication particuliers comme la diffusion, le point à point ou le multicast. A cette topologie de connexion sont associées des manières de gérer la répartition et la duplication des données. 3.1.Totalement connecté Figure 4 Architecture totalement connectée Dans cette représentation, les données de l environnement sont réparties ou dupliquées entre les différentes machines. Dans le cas où ces données sont dupliquées sur les différents sites, on parle d une architecture égal à égal. Dans une telle architecture, chaque site dispose d une copie complète de la base de données du monde. Toute modification d une copie par un site est transmise aux autres sites afin qu ils puissent maintenir leurs copies cohérentes. 11

12 3.2.Client / Serveur Figure 5 Architecture Client/Serveur Dans cette architecture, l état du monde est centralisé sur le serveur ou partiellement réparti / dupliqué entre les sites clients et le serveur. Dans le cas où les données sont réparties, les clients accèdent au serveur pour récupérer la partie de l état du monde qui les concernent. Le serveur a pour rôle de synchroniser les accès concurrents. Dans ce schéma, le serveur est clairement un goulot d étranglement si le nombre de clients ou la complexité du monde augmente. De plus, la latence de l accès au serveur rend cette solution un peu plus lente pour les clients. En général, au moins une partie de la base de données est dupliquée sur les sites clients. Le serveur joue alors le rôle d agent de routage : il régule le trafic entre les clients selon leurs besoins respectifs. 3.3.Client / Groupe de serveurs Figure 6 Architecture Client/Group des serveurs 12

13 Afin de diminuer le goulot d étranglement que constitue le serveur dans l architecture client - serveur, on peut utiliser plusieurs serveurs. Les serveurs se partagent ainsi la tâche de routage des messages inter client. Si la base de données est répartie et dupliquée entre les clients, les serveurs ont la charge du routage des messages de cohérence. Les serveurs servent de point d accès aux clients. Pour mieux répartir les charges, on peut mettre une partie de l environnement sur les serveurs. (par exemple, un serveur a la charge de détecter les collisions, alors qu un autre permet des accès à une base de données extérieure) Architecture multicast RESEAU MULTICAST Figure 7 Réseau multicast Dans ce schéma, c est le réseau qui prend en charge le routage sous l impulsion des différents sites. Le service multipoint se décrit comme le service permettant d'atteindre plusieurs destinataires ou plusieurs sites à partir d'un site émetteur sans pour autant faire une duplication de paquets pour chaque destination. Dans le mode multipoint, l'information est transmise vers un groupe de machines destinatrices sans faire circuler la même information plusieurs fois et économisant ainsi la bande passante disponible. L état du monde se trouve forcément sur les clients. L intérêt de ce type d architecture par rapport à l architecture précédente est que le routage, effectué par le réseau, impose une latence moindre pour le transit de l information d un client à un autre. L intelligence du filtrage est à la charge des clients qui doivent par ailleurs se concerter afin de maintenir cohérente la méta-information nécessaire à la bonne marche du filtrage. La mise en place d un sous-réseau multicast (comme l est le MBone sur Internet) nécessite des routeurs adaptés. Cette architecture est utilisée par de nombreux systèmes comme NPSNET, SPLINE et MASSIVE-2 13

14 3.5.Topologie à deux niveaux Figure 8 Topologie à deux niveaux Cette architecture tente de combiner les avantages d une architecture client / groupe de serveurs avec l utilisation des protocoles multicast. Prenons le cas où la base de données du monde virtuel est répartie et dupliquée sur les clients. Le sous-réseau de serveurs reliés entre eux par des groupes de communication multicast a la charge du routage des messages selon une stratégie de filtrage. Chaque serveur peut prendre en charge un certain nombre de clients (lesquels dépendront du type de filtrage effectivement mis en œuvre). Les serveurs utilisent les groupes multicast comme points de communication leur permettant de router les messages et de maintenir la cohérence entre les clients. Avec ce type d architecture, on décharge les clients du travail de filtrage et on peut d autre part exploiter un réseau à deux niveaux composé de liens à bas débit entre les clients et les serveurs et de liens à haut débit entre les serveurs. On pourrait également présenter d autres manières d exploiter ces schémas de distribution. Les manières de les exploiter sont nombreuses et dépendent des stratégies de filtrage et de cohérence que l on souhaite mettre en œuvre. 14

15 4.Approches du filtrage dans les environnements virtuels distribués 4.1.Première approche L approche la plus simple, notamment utilisée dans certains systèmes de jeux supportant le multi-joueur, est que chaque «site participant» diffuse l emplacement de chaque entité dont il a la propriété. Ces diffusions sont reçues par tous les sites participant à la simulation et sont utilisées pour mettre à jour leur copie locale de la «base de données de l environnement virtuel». Cette approche fonctionne convenablement sur les petits réseaux (LAN), cependant il persiste certains problèmes. Le problème le plus important avec la diffusion est que toutes les machines du réseau doivent recevoir et traiter les paquets pour la mise à jour. Ceci inclut même les machines qui ne participent pas à la simulation. De plus, cette technique génère un important trafic sur le réseau. Les obstacles majeurs de ces environnements virtuels distribués se situent principalement au niveau de l hétérogénéité des machines et des systèmes d exploitation des utilisateurs coopérant dans cet environnement, des temps de latence qui doivent être identiques, et aussi de la limite de la bande passante du réseau suivant le type de connexion utilisé. Le problème qui nous intéresse dans cette étude est celui des flux d information qui circulent entre les sites participant à l exécution de l environnement virtuel distribué. Ces flux sont la source de la congestion du réseau et de la surcharge des sites participants. Pour réduire ces effets, il faut réduire le trafic sur le réseau, ce qui réduit aussi la quantité de messages qui seront traités par les sites. Pour cela ; nous allons mettre en place des mécanismes de filtrage. Pour filtrer l information circulant entre les sites participant à l environnement virtuel, plusieurs approches sont envisageables : Réduire l encombrement des messages : la taille et la fréquence des messages sont liées au niveau d abstraction de l information qu ils contiennent. Le dead reckoning est un exemple d utilisation de messages plus abstraits qui permet d en réduire la fréquence d émission. En fait, le problème de l occupation de la bande passante du réseau est un sous problème du problème général de la compression de l information : pour réduire le trafic, il faut compresser, mais plus on compresse, plus le temps de calcul augmente à l émission comme à la réception (et donc la latence augmente). Pour optimiser le trafic, il faut compresser en fonction de la qualité de service requise par son destinataire. Réduire le nombre des destinataires d un message la prise en compte de l intérêt des différents sites est le meilleur moyen de réduire le nombre de messages envoyés 15

16 inutilement. Le filtrage selon l intérêt des entités peut être de différentes natures, comme par exemple : Filtrage spatial : une entité est intéressée par un ensemble d entités vérifiant certaines propriétés spatiales, comme la proximité. Filtrage fonctionnel : une entité est intéressée par un ensemble d entités vérifiant certaines fonctions applicatives, comme l accessibilité ou l adéquation à un service du point de vue d une entité. 4.2.Le filtrage selon NPSNET NPSNET (Naval Postgruate School s NETwork vehicle simulator) est une plate-forme de réalité virtuelle mettant en œuvre le protocole DIS[Zyda et al., 1992]. Elle est destinée principalement aux applications militaires. Les entités sont référencées dans une grille d hexagones. En partant du constat que les entités interagissent en général avec des entités voisines dans l espace, Michael Macedonia utilise une grille afin de déterminer ce voisinage. Deux entités interagissant pour cause de voisinage spatial sont dans la même classe spatiale, ce qui signifie que leurs zones d intérêt, exprimées par un ensemble de cellules hexagonales entourant chaque entité s intersectent. A chaque cellule, Macedonia associe un groupe multicast. En d autres termes, deux entités qui vont avoir des cellules en commun vont aussi avoir des groupes multicast en commun et vont par conséquent pouvoir s échanger des messages. Lorsque l entité se déplace, un certain nombre de cellules est retiré de la zone d intérêt et le même nombre y est ajouté. Macedonia utilise la distance Euclidienne comme critère de filtrage, elle est exprimée par un rayon autour des entités. Cellules qui vont être retirées Cellules qui vont être ajoutées Figure 9 Grille héxagonale Le filtrage proposé par NPSNET est destiné aux applications militaires à base de champs de bataille. En effet, la grille est bien adaptée au filtrage d entités se déplaçant au sol, 16

17 mais s avère en revanche peu adaptée au filtrage dans l espace tridimensionnel qui concerne les applications militaires spatiales, mais aussi toutes les applications exploitant les potentialités des environnements virtuels, comme les simulations mécaniques, les jeux, la visualisation de données scientifiques, etc. Macedonia propose cependant deux autres classes de filtrage qui ont un impact plus large : le filtrage fonctionnel et le filtrage temporel. Deux entités feront partie de la même classe fonctionnelle si elles ont un intérêt commun à propos duquel elles peuvent communiquer. La classe temporelle quant à elle, représente le caractère plus ou moins temps réel des communications entre entités. NPSNET a apporté des idées intéressantes sur le filtrage, bien que plus particulièrement axées sur les applications militaires. Le filtrage spatial tel qu il est mis en œuvre par NPSNET ne prend cependant en compte que la distance Euclidienne, ce qui peut s avérer restrictif et peu efficace dans certains cas. En effet, pour garantir la visibilité de gros objets éloignés, on est souvent obligé de considérer une distance de voisinage importante autour d une entité observatrice, ce qui du coup crée un grand nombre de PDU en provenance d entités plus petites, incluses dans ce voisinage, mais pas forcément perceptibles par l entité observatrice. 4.3.Le filtrage selon DIS Les protocoles multicast ont été abondamment explorés par la communauté DIS et restent une solution technique valide pour améliorer la robustesse face à la montée en charge. L utilisation du multicast est classée en trois catégories, en source-based (basé sur les sources), data-based (basé sur les données) et destination-based (basé sur les destinataires). Dans le multicast basé sur les sources, à chaque source de données est associé un groupe multicast auquel chaque site récepteur peut souscrire s il est intéressé. Un groupe additionnel est alimenté avec de l information à plus basse fidélité sur les différentes sources de sorte que les sites récepteurs puissent décider où se trouve leur intérêt et ainsi souscrire aux groupes multicast haute fidélité des sources correspondantes. Les sources peuvent être des entités ou bien des machines. Dans le premier cas, la précision du filtrage est meilleure, mais au prix d un nombre de groupes multicast plus important. Les sources ne changent jamais de groupe multicast, alors que les récepteurs en changent dès que des sources entrent dans leurs champs d intérêt ou en sortent. Grâce à l existence des groupes véhiculant l information à basse fidélité, les récepteurs peuvent prendre en compte, dans leur décision d abonnement, le temps nécessaire pour que la souscription à un groupe multicast prenne effet, ceci afin de ne pas être surpris par cette latence. En effet, on l a dit, le problème principal des protocoles multicast est la latence d abonnement ou désabonnement. Pour contourner cette latence, il faut tenter de rejoindre et quitter les groupes multicast par anticipation. Le multicast basé sur les sources est moins affecté par ce problème que les deux types d utilisation des protocoles multicast que nous allons présenter maintenant. Le multicast basé sur les données couvre la majorité des utilisations du multicast dans DIS et dans les systèmes de réalité virtuelle distribuée. Emetteur et récepteur doivent gérer leur abonnement aux groupes multicast, et à la différence du multicast basé sur les sources, on ne permet pas au réseau d anticiper pour ajouter un membre à un groupe multicast. 17

18 Pour le multicast basé sur les destinataires, les groupes sont associés aux destinataires et c est la source qui doit déterminer la liste des destinataires auxquels elle doit souscrire, en prenant compte de l expression de leurs intérêts. Un groupe multicast est créé pour chaque liste de destinataires. Ce mode d utilisation du multicast est très consommateur de groupe. Bien que DIS ait exploré abondamment les protocoles multicast afin d améliorer la robustesse face à la montée en charge des simulations distribuées, il n y a pas eu de retour de ces avancées jusqu au niveau de la standardisation. Il a fallu attendre HLA (High Level Architecture) pour qu une tentative de rationalisation du problème de filtrage apparaisse. 4.4.Le filtrage selon HLA Le département de la défense Américain (DoD), sous la direction du bureau de modélisation et de simulation pour la défense (DMSO) [Van Hook et al., 1996], développe une architecture de haut niveau pour la modélisation et la simulation. Le but principal d'une telle architecture est de faciliter l'interopérabilité et la réutilisation de simulations à travers de nombreuses d applications. Ce but est très semblable à ceux déjà défini par la communauté de DIS, mais ils ont focalisé sur un ensemble plus large de simulations que DIS, par exemple, des simulations incorporant des événements programmables, et d'autres mécanismes de gestion de temps. HLA définit un certain nombre de termes et de concepts. Les fédérations regroupent des fédérés participant à la simulation. Les fédérés sont par exemple des modèles de simulation, des collecteurs d information, des simulateurs, des entités réelles Une session de simulation à laquelle participe un certain nombre de fédérés s appelle une exécution. Les entités simulées, tels les tanks et les avions, sont nommées objets ; et sont gérées par les fédérés. L état de chaque objet est défini par ses attributs. Les objets interagissent les uns avec les autres grâce à des interactions. Toutes les interactions possibles entre les fédérés sont définies grâce à un modèle objet de fédération (Federation Object-Model ou FOM). Les capacités des fédérés sont définies grâce à un modèle objet de simulation (Simulation Object-Model ou SOM). Le FOM est en fait l agrégation des différents SOM utilisés par les différents fédérés. Le SOM a été introduit afin d améliorer la réutilisabilité des simulations (un SOM peut en effet être partagé par plusieurs fédérés). 18

19 SIMULATION SIMULATION SIMULATION RUNTIME INFRASTRUCTURE SIMULATION SIMULATION SIMULATION ARCHITECTURE DE HLA Figure 10 Architecture de la RTI En se basant sur l expérience acquise par DIS au niveau de l utilisation de protocoles multicast, HLA propose des approches standardisées pour filtrer l information circulant sur le réseau. HLA a introduit dans le cadre de la gestion des données distribuées (distributed data management) le concept important d espace de routage (routing space). L'interface entre le réseau actif et le RTI a été mise en application par la fonction de gestion de distribution de données (DDM) de HLA. Cette gestion fournit les mécanismes qui permettent au RTI de contrôler la distribution des données basées sur des attributs des données. Dans DDM comme spécifié par HLA, un espace de routage est «un système de coordonnées multidimensionnel au sein duquel les fédérés expriment leur intérêt à recevoir des attributs et des interactions de la part d autres fédérés ou à envoyer des attributs et des interactions aux autres fédérés». En s appuyant sur l expression de l intérêt d un fédéré, le RTI doit établir la connectivité réseau qui va minimiser le trafic inutile. Un espace de routage se compose de régions de souscription et de régions de mise à jour. Les régions de souscription permettent à un fédéré d exprimer ce qui l intéresse et les régions de mise à jour ce qu il souhaite fournir. Le chevauchement des régions de souscription et de mise à jour informe le RTI de la dépendance entre les fédérés et par conséquent de la connectivité réseau qu il est nécessaire d établir. Les espaces de routage définis par HLA permettent d implanter un certain nombre de schémas de connectivité multicast. Le filtrage géographique basé sur des grilles pourrait par exemple être implanté en utilisant une région par cellule. Une fédération peut définir plus d un espace de routage, chacun répondant à un besoin spécifique, et ayant la structure de base suivante : un certain nombre de dimensions et une 19

20 variable de routage pour chaque dimension. Les régions sont définies par une étendue faite de paires de points extrémités pour chaque dimension. Les régions sont donc des portions "rectangulaires" de l espace de routage qui définissent les zones de souscription et de mise à jour des fédérés. 4.5.Le filtrage selon SPLINE SPLINE (Scalable PLatform for INteractive Environments) a été développée au MERL (Mitsubishi Electric Research Laboratory). L objectif de cette plate-forme est de permettre la mise en œuvre d environnements virtuels partagés de grande taille. Pour cela, SPLINE utilise un découpage de l espace en zones ou cellules, appelées des locales. SPLINE propose un mécanisme de structuration de l espace en cellules. L espace est segmenté en locales qui sont traitées de manière indépendante. Cela facilite la modélisation des environnements virtuels mais également leur gestion. Chaque locale est gérée individuellement (sa cohérence sur les différents sites est maintenue via le groupe multicast qui lui est associé). Le graphe de locale permet la mise en œuvre d un filtrage basé sur le voisinage. Ces cellules sont prédéterminées au moment de la conception de l application. En effet, les locales exploitent en général certaines caractéristiques géométriques des applications comme par exemple les frontières naturelles de la perception que sont les murs. Mais les locales peuvent aussi changer dynamiquement au cours de l exécution de l application. Cependant, la structuration de l espace en locale est une approche moins générique que la grille de Macedonia, même si elle peut s avérer plus efficace dans certaines situations. Enfin, les locales décrivent un filtrage basé sur l éloignement et non la réelle pertinence vis à vis de la perception. Les locales permettent cependant de mettre en œuvre un filtrage prenant en compte une partie de la visibilité réelle des entités (on peut filtrer les entités cachées par les frontières des locales, mais on ne peut cependant pas prendre en compte les occlusions interentités). 4.6.Le filtrage selon MASSIVE MASSIVE (Model Architecture and System for Spatial Interaction in Virtual Environments) est une plate-forme développée à l Université de Nottingham. Cette plateforme présente une approche intéressante du filtrage basé sur le modèle d interaction spatial. Selon ce modèle, un environnement virtuel est décrit par un espace, lui-même réparti en différents médiums (graphique, audio, texte, etc.). A chaque objet est associée une aura qui caractérise l étendue d espace dans laquelle les interactions avec l objet sont possibles. L aura dépend entre autres de la position de l objet. Une interaction entre deux objets ne peut intervenir que lorsque leurs auras respectives entrent en collision. En pratique, aura est décrite par des fonctions analogues à des champs de potentiel définis dans l espace. Ces fonctions servent à déterminer la perception mutuelle des objets. Et c est sous condition de perception mutuelle que des informations sont effectivement échangées entre les objets. Après l évaluation des différentes fonctions sur les différents 20

21 objets, les informations issues de ce filtrage peuvent circuler sur le réseau entre les objets hébergés par les différentes machines. Dans la nouvelle plate-forme distribuée MASSIVE 2, le concept d objet tiers a été ajouté. L objet tiers est un intermédiaire dans la relation de perception qui lie deux objets normaux. Les objets tiers agissent comme des structures qui non seulement segmentent l espace (à la manière des locales de SPLINE ici aussi, à chaque objet tiers correspond un groupe multicast), mais aussi «agrègent» les activités des objets qui leur sont liés. L agrégation d activité consiste à combiner les nombreux flux d information issus des objets en un seul, issu de l objet tiers. Cette capacité d agrégation, qui dépend de la nature de l information agrégée, est un outil puissant pour réduire le trafic. C est un avantage supplémentaire par rapport à SPLINE qui ne propose que la possibilité de segmentation. Les relations entre objets et tiers peuvent être de diverses natures : les cellules sont des éléments structurant élémentaires, les pièces et bâtiments agissent sur la visibilité, les foules agrègent leurs participants, etc. Le modèle à base d objets tiers est puissant et permet d exprimer un nombre important de relations entre les objets d un environnement virtuel. Cette structuration de l environnement virtuel est non seulement à caractère sémantique (elle exprime des relations particulières qui aident à la conception des applications), mais sert également de support aux techniques de filtrage de l information transmise au sein de l environnement virtuel. Les objets tiers sont un concept très puissant pour caractériser les échanges d information au sein de l environnement virtuel. Les objets tiers sont cependant assez dépendants des applications (même s il est possible d en concevoir des génériques), ce qui impose quelques contraintes d utilisation. 4.7.Le filtrage selon WAVES WAterloo Virtual Environment System, a été développé par Rick Kazman [Kazman, 1993c] [Greenhalgh et Benford, 1995] à l Université de Waterloo, supporté par une architecture logicielle ouverte, client/serveur, a identifié des notions intéressantes comme la séparation des intérêts (separation of concerns), ainsi que l utilité d une bonne gestion de l espace. Par séparation des intérêts, Kazman insiste sur l importance de mettre en œuvre une gestion de l intérêt qu ont les entités pour les diverses natures d information qui composent un environnement virtuel. Il a souligné là ce qui constitue la base du filtrage d information dans les environnements virtuels. Kazman s est aussi intéressé à la structuration spatiale en développant un gestionnaire de zones censé partitionner le trafic sur le réseau en fonction des relations spatiales entre les entités. 4.8.Le filtrage selon VIPER VIPER Virtuality Programming EnviRonment, a été développé par Patrice Torguet [Torguet, 1998] à l IRIT. Ce système de réalité virtuelle distribué utilise un algorithme de structuration spatiale pour les bâtiments, issu d un article de Luebke. Cet algorithme permet 21

22 une segmentation en cellules un peu analogue à celle utilisée par Funkhouser dans RING. Un graphe de pièces est créé qui va permettre de déterminer les pièces appartenant au voisinage d un observateur (celles qui sont visibles au travers des portes de la pièce où se trouve l observateur). Contrairement à la technique de Funkhouser [Funkhouser, 1996], l intervisibilité des pièces n est pas précalculée, mais les pièces visibles sont déterminées à la volée en fonction de la position et de l orientation de l observateur dans la pièce. Cela permet une évaluation plus précise du voisinage car l ensemble des pièces voisines, qui est ici déterminé récursivement (à partir du graphe), est nécessairement inclus dans l ensemble des pièces voisines selon l algorithme de Funkhouser. 4.9.Le filtrage selon DIVE Distributed Interactive Virtual Environment, est développé par le SICS (Swedish Institute of Computer Science) [Andersson et al. 1994]. DIVE est une plate-forme de réalité virtuelle très complète basée sur une architecture distribuée du type égal à égal. DIVE supporte les protocoles multicast au travers du DiveBone, une sorte de Mbone destiné à la communication entre les processus DIVE tournant dans des sous-réseaux multicast. Par défaut, DIVE associe des groupes multicast aux mondes DIVE, c est-à-dire à des parties disjointes de la base de données globale. Mais DIVE peut aussi assigner des groupes multicast à des niveaux de granularité plus fins : à toute hiérarchie d objets de la scène il est possible d associer un groupe multicast. Ainsi, seuls les objets de cette hiérarchie sont en communication. Un groupe peut cependant être associé à plusieurs hiérarchies et également changer dynamiquement d assignation, ce qui confère une certaine souplesse au système. Ces mécanismes sont intéressants mais restent cependant d assez bas niveau. DIVE ne propose pas encore de véritable stratégie de filtrage comme c est le cas pour MASSIVE et SPLINE. Il existe encore bien d autres systèmes virtuels, cependant peu se sont vraiment intéressés au problème du filtrage distribué. Ce survol a pour objectif de décrire le contexte technique des environnements virtuels distribués. Nous avons pu constater que le maintien de la cohérence est un problème crucial pour les environnements virtuels distribués. Elle est souvent confrontée aux contraintes de l infrastructure du système comme la limitation de la bande passante du réseau qui nécessite de réduire la quantité d information qui y circule. Pour contourner cette contrainte liée au trafic du réseau, nous allons dans la deuxième partie utiliser et implémenter des méthodes de filtrage permettant de réduire le transfert des messages sur le réseau. 22

23 SECONDE PARTIE Analyse des problèmes du filtrage et Implémentations 23

24 5.PRESENTATION D HLA HLA fournit une architecture pour la modélisation et la simulation. Cette architecture a pour objectif de favoriser l'interopérabilité des simulations et la réutilisation des composants de simulation dans le cadre du DoD. HLA est défini par trois concepts : L Object Model Template (OMT) L infrastructure d exécution RTI Les règles de conformité de HLA Le RTI et les règles de conformité sont inchangés à travers toutes les simulations basées sur le concept d HLA. Cependant, chaque groupe interagissant dans les simulations ou à la fédération 1, doit définir une base pour l'échange de données et des événements entre des simulations. publishobjectclass subscribeobjectclass Attribute Federate Federate Ambassador Federate Federate Ambassador RTI Ambassador RTI Ambassador updateattributevalues startupdates RTI reflectattributesvalue s Figure 11 Schéma de fonctionnement de la RTI L Object Model Template de HLA est un formalisme qui permet de décrire d une façon orientée objet les entités utilisées durant l exécution d une fédération et les interactions possibles entre ces entités. Ce formalisme est un support d échange standardisé entre les développeurs participant à une fédération, mais il est aussi et surtout une aide importante en vue de la réutilisation des modèles objets ainsi documentés par OMT. 1 Fédération : Ensemble de fédérés qui interagissent en utilisant un modèle objet commun de fédération. 24

25 Les règles de conformité sont généralement de la forme : Les fédérations doivent avoir un FOM 2. Tous les fédérés doivent avoir un SOM 3. Toute la représentation des objets se trouve au niveau des fédérés 4 et non pas dans le RTI. L infrastructure d exécution (RTI) fournit un ensemble de services communs qui sont utiles à travers des domaines de simulation multiples. Ces services communs sont divisés en cinq catégories : Gestion de la fédération (Federation Management) Gestion des déclarations (Declaration Management) Gestion des objets (Object Management) Gestion de la propriété (Ownership Management) Gestion du temps (Time Management) Gestion de la fédération : Ces services permettent à un fédéré de créer/détruire l exécution d une fédération, de rejoindre/quitter l exécution d une fédération existante, de mettre l exécution de la fédération en pause et de charger/sauvegarder une exécution de fédération. Gestion des déclarations : La gestion des déclarations est un ensemble de services permettant de déclarer au RTI que le fédéré veut publier certaines classes d objets ou d interactions, ou s y abonner. La simulation ayant souscrit à telle classe d objets (resp. d interaction), le RTI s engage à lui donner tous les messages (création/destruction d objets, changement des valeurs d attributs des objets, réception d interactions) émis par d autres fédérés qui publient des objets (resp. interaction) de cette classe. Gestion des objets : Cet ensemble de services sert principalement à gérer la création/destruction d instances de classes d objets ou d interactions, et la modification des valeurs d attributs d objets. Gestion de la propriété : Dans HLA, le fédéré qui crée un objet ne contrôle pas forcément tous les attributs de cet objet. En effet, chaque attribut d un objet a un propriétaire (par défaut, tous les attributs d un objet venant d être créé appartiennent au fédéré créateur) et ce droit de propriété peut être passé d un fédéré à un autre grâce aux services de la gestion de propriété. Par contre, le propriétaire d un attribut s engage à tenir à jour la valeur de l attribut et à informer le RTI de toute modification. Gestion du temps : Les services de la gestion du temps permettent à un fédéré d avancer dans le temps d une façon coordonnée par rapport à d autres fédérés selon l horloge logique de chacun d eux. L utilisation d une horloge logique permet de simuler un phénomène sur une longue durée. Gestion de la distribution de données (DDM) : Les services de la gestion de la distribution des données, ajoutés à ceux de la gestion des déclarations, permettent de moduler 2 FOM : Federation Object Model (Modèle objet commun de fédération). 3 SOM : Simulation Object Model (Modèle objet commun de simulation). 4 Fédéré : Un membre d une fédération HLA. 25

26 l abonnement à une classe d objets (resp. d interaction) en donnant des intervalles de valeurs pour certains attributs de la classe. Le gestion de la distribution est en fait une technique de filtrage des informations qui permet au RTI de réduire des échanges de messages. La gestion de la distribution des données s appuie sur les concept «d espace de routage» (routing space). Pour utiliser la gestion de distribution de données du RTI, chaque fédération définit les espaces de routage autorisés pendant une exécution. Ils sont ensuite spécifiés dans le fichier d initialisation FED en leur attribuant un nom et un nombre de dimensions. Chaque fédéré décide lesquels des espaces de routage lui sont utiles et définit des régions qui sont des sousensembles de ces espaces. Il existe deux types de régions : les régions d abonnement et celles de mise à jour. Grâce à une région d abonnement, un fédéré peut indiquer au RTI de ne lui délivrer que des données qui sont comprises entre les bornes de la région. Chaque fédéré peut créer plusieurs régions des deux types. Le schéma suivant indique une région de mise à jour (U) et deux régions d abonnement (S1 et S2) dans un espace de routage à deux dimensions. Comme U et S1 se chevauchent, les attributs et les interactions associés avec U seront routés par le RTI vers le fédéré qui a crée S1. Par contre, étant donné que U et S2 ne se chevauchent pas, les attributs et les interactions associés à U ne seront pas routés vers le fédéré qui a crée S2. S1 U S2 Figure 12 Exemple d espace de routage 26

27 Services de Gestion de la distribution de données Spécification des services Description RTI 1.3v6 RTI::RTIAmbassador:: 1. Create Region Création d une nouvelle région CreateRegion() 2. Modify Region Ce service informe le RTI des changements des régions NotifyAboutRegionModificati on () 3: Delete Region Ce service supprime les régions qui ne sont pas utilisées. 4: Register Object Ce service enregistre un nouvel objet Instance With Region de la fédération et associe certains ou tous les attributs de l objet aux services de la gestion de la 5: Associate Region For Update 6: Unassociate Region For Updates 7: Subscribe Object Class Attributes With Region 8: Unsubscribe Object Class With Region 9: Subscribe Interaction Class With Region 10: Unsubscribe Interaction Class With Region 11: Send Interaction With Region 12: Request Attribute Value Update With Region distribution des données Associe la région de mise à jour et l instance des attributs pour l instance d objet spécifié. Supprime l association des régions et des instances d attributs. Ce service permet la livraison au fédéré des mises à jour des instances d'un ensemble de classe d attributs, qui sont enregistré dans les sous régions Termine les découvertes des classes Ce service permet la livraison d interactions au fédéré d'une classe indiquée et spécifiée dans un sous espace spécifié Arrêt de l envoi des interactions Ce service fournit une interaction aux fédérés qui sont abonnés à la région Stimule la mise à jour des valeurs des attributs indiqués. Initialisation des intervalles des fédérés avec des functions : Set Upper Bound Set Lower Bound DeleteRegion() RegisterObjectInstanceWithRe gion () AssociateRegionForUpdates() UnassociateRegionForUpdates () SubscribeObjectClassAttribute swithregion() (A.6.9) UnsubscribeObjectClassWithR egion () SubscribeInteractionClassWith Region() UnsubscribeInteractionClassW ithregion() SendInteractionWithRegion() RequestClassAttributeValueUp datewithregion () 27

28 6.METHODES ET IMPLEMENTATIONS DU FILTRAGE 6.1.Dead-reckoning L'idée du dead reckoning est simple : au lieu d'envoyer juste l'emplacement d'une entité, une machine envoie un message qui contient l'emplacement de l'entité, une estampille temporelle, et un vecteur vitesse. En utilisant cette information, chaque hôte dans le réseau peut alors extrapoler l'emplacement de l'entité sans mises à jour supplémentaires. Ceci peut être fait pour l'orientation de l'entité aussi bien que pour l'emplacement. Chaque entité gère sa propre simulation, et également le modèle prédictif de son propre comportement (extrapolation utilisant les données envoyées sur le réseau). Elle compare l'emplacement calculé par les deux modèles ; quand ils divergent de plus qu'une certaine quantité, elle envoie une nouvelle mise à jour sur le réseau pour signaler sa nouvelle position aux autres entités. Le dead reckoning produit des résultats significatifs. Puisque des mises à jour sont seulement envoyées lorsque c est nécessaire, la quantité de trafic est considérablement réduite. Ce modèle est bien adapté aux simulations de guerre car les entités sont des véhicules et des projectiles qui répondent bien aux règles d utilisation du dead reckoning (leur vecteur vitesse reste constant pendant de long moments) Implémentation Je suis parti d une simulation de tank développé à l IRI.T, qui utilise la RTI du DMSO comme système de distribution. Au niveau de l implémentation, j ai ajouté une classe TankGhost qui permet d associer un tank fantôme à un tank local. Ainsi lorsque la distance euclidienne entre le tank local et le tank fantôme est supérieur à un seuil fixé alors une mise à jour sera envoyée sur le réseau pour prévenir autres participants de sa nouvelle position. 28