Environnements virtuels distribués

Environnements virtuels distribués
A. Branzan-Albu et D. Laurendeau Dép. de génie électrique et de génie informatique Université Laval

Introduction Définition, caractéristiques et défis posés aux environnements virtuels répartis

Qu’est-ce qu’un EV distribué?
C’est un environnement virtuel: Où plusieurs utilisateurs peuvent interagir en temps réel même si ces utilisateurs sont situés à des lieux physiques différents Qui permet aux utilisateurs de percevoir les informations visuelles en trois dimensions Qui permet aux utilisateurs de percevoir les informations sonores en stéréo A. Branzan-Albu & D. Laurendeau GIF-66800

Caractéristiques recherchées
Un EV distribué devrait offrir aux utilisateurs: Un sens de partage de l’espace virtuel (« shared sense of space ») i.e. un participant a l’impression d’être dans le même lieux physique que les autres Un sens de présence: un utilisateur occupe l’environnement virtuel grâce à un avatar et a conscience de la présence des autres utilisateurs grâce à leurs avatars Un sens de partage du temps: un utilisateur devrait percevoir les événements survenant dans l’EV en même temps que les autres Un ou des moyens de communication par exemple via des interfaces haptiques, visuelles ou graphiques Un ou des moyens de partager et d’interagir de manière réaliste avec les objets du monde virtuel et avec l’environnement lui-même A. Branzan-Albu & D. Laurendeau GIF-66800

Défis posés aux EV distribués
Les EV distribués Sont soumis aux contraintes du réseau: délais, collisions, jitter, pertes de communication, partage des ressources de bande passante; Doivent assurer des performances d’affichage graphique acceptables afin que l’évolution du monde virtuel soit réaliste et perceptuellement correcte Doivent assurer un niveau acceptable d’interactivité en temps réel (input en temps réel des utilisateurs pour modifier le monde, etc.) A. Branzan-Albu & D. Laurendeau GIF-66800

Défis posés aux EV distribués (2)
Les EV distribués Doivent intégrer des bases de données sur les propriétés du monde et de ses composantes Doivent éventuellement permettre d’identifier les participants (« user authentification ») Doivent permettre de stocker l’évolution du monde à un moment donné afin de le réactiver plus tard. A. Branzan-Albu & D. Laurendeau GIF-66800

Les EV distribués Doivent tenir compte des limites de bande passante sur le réseau et du type de connexion des utilisateurs (haute vitesse, modem, etc.) Doivent assurer un fonctionnement en temps réel Single-threaded Multi-threaded Rafraîchissement graphique Interaction avec les utilisateurs Accès aux données partagées A. Branzan-Albu & D. Laurendeau GIF-66800

Les EV distribués Doivent prévoir les cas de panne et d’interruption de fonctionnement Arrêt du système: peut causer la perte des résultats d’une simulation Fermeture du système: peut interrompre l’accès à de nouveaux utilisateurs sans perturber les utilisateurs existants Dégradation du système: quelques composantes d’un système peuvent fonctionner de manière sous-optimale sans interrompre la simulation A. Branzan-Albu & D. Laurendeau GIF-66800

Les EV distribués Doivent pouvoir être « scalés » pour permettre une croissance dans les simulations Nombre d’entités Nombre d’utilisateurs La « scalabilité » a une complexité qui croît de manière exponentielle avec le nombre d’entités qui peuvent interagir entre elles A. Branzan-Albu & D. Laurendeau GIF-66800

Les EV distribués Doivent pouvoir être déployés et configurés facilement, spécialement pour ceux faisant appel à l’Internet A. Branzan-Albu & D. Laurendeau GIF-66800

Communications réseau
Notions et concepts de base

A. Branzan-Albu & D. Laurendeau GIF-66800
Notion de réseau Définition de réseau en EV distribués: medium pour l’échange de données et d’information entre plusieurs hôtes participant à une expérience virtuelle partagée A. Branzan-Albu & D. Laurendeau GIF-66800

Notions fondamentales de transfert de données (1)
Latence de réseau: temps requis pour transférer un bit de data d’un point à un autre La latence a un impact direct sur: Le réalisme d’une expérience virtuelle Les concepteurs d’EV ne peuvent rien contre la latence A. Branzan-Albu & D. Laurendeau GIF-66800

Latence du réseau (2) Origines de la latence: Limites physiques de la vitesse de la lumière dans les fibres optiques, il faut 21 ms pour transmettre un message de l’atlantique au pacifique. Cette durée est supérieure pour les liens satellites Délais de traitement par les ordinateurs hôtes causés par le hardware et le software A. Branzan-Albu & D. Laurendeau GIF-66800

Latence du réseau (3) Origines de la latence (2): Délais dans le réseau lui-même causés par l’instrumentation réseau: routeurs, commutateurs, etc. A. Branzan-Albu & D. Laurendeau GIF-66800

Latence du réseau (4) Ordre de grandeur des délais de latence: Variable: Ethernet (LAN): 10 ms Modem: 100 ms Ethernet (WAN) Transcontinental: ms Intercontinental: ms A. Branzan-Albu & D. Laurendeau GIF-66800

Bande passante: taux avec lequel le réseau peut transférer les données entre l’ordinateur source et l’ordinateur destination Elle est limitée par le type de substrat sur lequel les données sont transmises (câble, fibre) A. Branzan-Albu & D. Laurendeau GIF-66800

Bande passante (2) La bande passante est aussi limitée par le hardware de transmission Modem: 14 Kbps à 56 Kbps/s (limite physique de la ligne téléphonique elle-même est de 64 Kbps) Ethernet: 10 Mbps, 100 Mbps, 1 Gbps Fibres optiques modernes: 10 Gbps A. Branzan-Albu & D. Laurendeau GIF-66800

Distinction entre latence et bande passante: Bande passante: nombre de bits par seconde qui peuvent passer dans un medium (si on les regardait passer) Latence: délai du transfert, soit le temps nécessaire au transfert d’un bit d’un point à un autre A. Branzan-Albu & D. Laurendeau GIF-66800

Distinction entre latence et bande passante
Latence et bande passante décrivent un réseau, mais ne sont pas reliées: Un réseau à grande largeur de bande peut avoir une latence faible Un réseau à faible bande passante peut avoir une grande latence A. Branzan-Albu & D. Laurendeau GIF-66800

Fiabilité du réseau: Mesure qui donne les performances du réseau quant à la quantité des données qui sont perdues entre la source et la destination A. Branzan-Albu & D. Laurendeau GIF-66800

Fiabilité du réseau (2) 2 catégories de défaillances du réseau: « dropping »: les données émises par la source n’atteignent jamais la destination parce qu’elles ont été détruites par le réseau « corruption »: les données se rendent de la source à la destination, mais sont inutilisables car elles ont été modifiées durant leur trajet A. Branzan-Albu & D. Laurendeau GIF-66800

Fiabilité du réseau (3) Causes principales du manque de fiabilité: Mauvaises connexions (rare): 1 bit/1010 sur les réseaux câblés. Cette performance est plus réduite sur les réseaux sans fil. Routeurs de réseaux: les erreurs sont particulièrement causées par des quantités trop importantes de données à traiter par rapport aux ressources de calcul disponibles. En période de pointe, les pertes peuvent être de 50%...pour être négligeables à d’autres moments. A. Branzan-Albu & D. Laurendeau GIF-66800

Fiabilité du réseau (4) Méthodes utilisées pour augmenter la fiabilité du réseau: Utilisation de « checksums » transmis avec les données et vérifiés par le destinataire. Certains systèmes possèdent aussi des codes correcteurs d’erreur. Utilisation d’un protocole basé sur un « accusé de réception » (acknowledge): si une source ne reçoit pas un accusé de réception d’une destination après un certain laps de temps, elle retransmet les données en faisant l’hypothèse qu’elles ont été perdues. A. Branzan-Albu & D. Laurendeau GIF-66800

Protocoles réseau Un protocole est un ensemble de règles que deux applications respectent pour communiquer entre elles A. Branzan-Albu & D. Laurendeau GIF-66800

Protocoles réseau Un protocole repose sur: Un format de paquets de données qui décrit à quoi les données ressemblent Une sémantique de paquets qui décrit comment les paquets sont structurés Une politique de traitement des erreurs A. Branzan-Albu & D. Laurendeau GIF-66800

Protocoles réseau (2) Il existe des milliers de protocoles réseau Les machines utilisent souvent plusieurs protocoles pour accomplir diverses tâches A. Branzan-Albu & D. Laurendeau GIF-66800

Communications réseau
L’architecture des sockets BSD

Les sockets BSD L’architecture des sockets BSD permet aux machines qui envoient et recoivent des paquets de données de décider à quelle application ces paquets sont destinés L’architecture des sockets BSD repose sur deux éléments principaux: Les sockets Les ports A. Branzan-Albu & D. Laurendeau GIF-66800

Les sockets BSD (2) Les applications communicant par le réseau le font via un « socket » Un « socket » est une représentation abstraite d’un point terminal d’un canal de communication Les sockets peuvent représenter plusieurs types de canaux de communication A. Branzan-Albu & D. Laurendeau GIF-66800

Les sockets BSD (3) Schéma type d’une communication par sockets: L’hôte source transmet un paquet d’information sur le socket en incluant Le type de protocole L’adresse de l’ordinateur hôte (réception) Le numéro de port de l’application (réception) L’adresse de l’ordinateur source (transmission) Le port de l’application d’envoi A. Branzan-Albu & D. Laurendeau GIF-66800

Les sockets BSD (3) Les sockets peuvent représenter plusieurs types de canaux de communication: Communications fiables avec destination unique Communications peu fiables avec destination unique Communications fiables avec destinations multiples Communications mémoire avec une autre application sur la même machine Peu importe le type de canal de communication, l’application voit une abstraction unique A. Branzan-Albu & D. Laurendeau GIF-66800

Les sockets BSD (4) Un socket identifie au moins les 5 types d’information suivants sur un canal de communication: Le protocole: comment le système d’exploitation gère l’échange d’information (avec acknowledge ou non, etc.) L’hôte de destination de l’information: adresse de réception de l’information transmise sur ce socket A. Branzan-Albu & D. Laurendeau GIF-66800

Les sockets BSD (5) Numéro d’identification de l’application (ID), ou port: ce numéro identifie le port approprié sur l’hôte de destination. Pour chaque protocole, chaque port est numéroté grâce à un nombre entier codé sur 16 bits. En spécifiant le protocole et le numéro de port dans chaque paquet d’information, la source s’assure que la destination peut fournir l’information à la bonne application A. Branzan-Albu & D. Laurendeau GIF-66800

Les sockets BSD (5) Numéro de l’ordinateur hôte: cette adresse identifie l’ordinateur qui transmet les informations. Ce numéro est rarement utilisé sauf lorsque l’ordinateur est muni de plusieurs cartes de communication réseau Numéro local de l’application (ou numéro de port): nombre de 16 bits identifiant l’application qui transmet l’information sur le socket. Avec le numéro de l’ordinateur hôte, ce numéro permet à l’hôte de destination de transmettre des paquets en réponse à l’application source. A. Branzan-Albu & D. Laurendeau GIF-66800

Les ports (1) L’utilisation des ports est l’un des fondements de la communication par sockets Chaque application choisit un numéro de port et, en diffusant ce numéro avec l’adresse hôte, s’assure que d’autres applications peuvent s’y connecter et y transmettre des informations Il existe ports. Les systèmes d’exploitation peuvent donc supporter plusieurs applications simultanément A. Branzan-Albu & D. Laurendeau GIF-66800

Les ports (2) Deux applications qui communiquent entre elles ne sont pas tenues d’utiliser le même numéro de port Chaque hôte attribue les numéros de port aux applications de manière indépendante et chaque paquet contient donc à la fois le numéro de port source et ne numéro de port destination A. Branzan-Albu & D. Laurendeau GIF-66800

Les ports (3) Si les numéros de port sont arbitraires, comment une application fait-elle pour en trouver une autre afin d’établir une communication? Par exemple, comment un fureteur peut-il savoir le numéro de port à utiliser pour parler aux serveurs WWW? A. Branzan-Albu & D. Laurendeau GIF-66800

Les ports (4) Réponse: Les numéros de port entre 1 et 1023 sont réservés pour des applications courantes connues des systèmes d’exploitation Les numéros de port 1024 à sont enregistrés pour être utilisés par des protocoles bien connus A. Branzan-Albu & D. Laurendeau GIF-66800

Les ports (5) Réponse (suite): Par exemple, le protocole HTTP utilise le serveur 80 Le port 25 est utilisé par le protocole SMTP pour le service de courriel Le port 1080 est utilisé pour définir un périmètre de sécurité de pare-feu L’assignation des numéros de port est sous le contrôle de IANA (Internet Assigned Numbers Authority) A. Branzan-Albu & D. Laurendeau GIF-66800

Les ports (6) Conséquences sur le design d’applications de VR distribuée: L’application de VR doit utiliser un numéro de port non enregistré L’usage recommande d’utiliser un numéro de port entre et 65532 Si une application devient populaire, il est préférable de demander un numéro enregistré à l’IANA A. Branzan-Albu & D. Laurendeau GIF-66800

Le protocole IP (Internet Protocol)
Notions de base

Introduction La grande majorité des ordinateurs utilisent le protocole IP pour communiquer IP est un protocole de bas niveau utilisé par les ordinateurs et les routeurs dans le but de transmettre des informations d’un point à un autre A. Branzan-Albu & D. Laurendeau GIF-66800

Introduction (3) Le protocole IP cache aux ordinateurs le fait que le canal de transmission puisse être hétérogène (i.e. contenir des liens téléphoniques, des liens à fibres optiques et des liens sans fil) IP inclut des fonctionnalités pour la segmentation et le réassamblage (SAR) des paquets L’en-tête de IP contient aussi un champ TTL (Time-To-Live) qui spécifie le nombre maximum de fois qu’un paquet peut être relayé, ce qui empêche que le même paquet soit relayé infiniment A. Branzan-Albu & D. Laurendeau GIF-66800

Les protocoles Internet pour les EV distribués
TCP, UDP, Multicasting et Broadcasting

Le protocole TCP Transmisssion Control Protocol (TCP) est le protocole le plus fréquemment utilisé sur Internet TCP est implanté au-dessus de IP et en exploite les services de bas niveau, d’où l’appellation fréquemment rencontrée de TCP/IP A. Branzan-Albu & D. Laurendeau GIF-66800

Le protocole TCP (2) TCP/IP donne l’impression à une application qu’elle entretient une communication point-à-point avec une autre application A. Branzan-Albu & D. Laurendeau GIF-66800

Le protocole TCP (3) Principales caractéristiques de TCP/IP: Connexion point-à-point bi-directionnelle Utilisation de messages d’accusé de réception (acknowledge) Retransmission des paquets perdus Sémantique de protocole de type « stream » (i.e. les données sont ordonnées et les messages transmis sont ré-assemblés dans le bon ordre par l’hôte de réception La connexion s’assure que le flot de transmission ne dépasse pas la capacité du réseau ni la puissance de calcul de l’unité de réception A. Branzan-Albu & D. Laurendeau GIF-66800

Le protocole UDP User Datagram Protocol (UDP) est un protocole léger pour la communication entre applications A. Branzan-Albu & D. Laurendeau GIF-66800

Le protocole UDP (2) Principales caractéristiques de UDP: Contrairement à TCP, UDP n’assure pas une connexion entre les participants d’une communication (aucune information sur l’état de la communication n’est conservé) Transmission « best-effort » des paquets (i.e. aucun accusé de réception ni retransmission des paquets perdus. Un paquet perdu ne pourra jamais être retrouvé!) Sémantique de protocole basée sur les paquets (les données sont transmises un paquet à la fois indépendamment des autres paquets) UDP requiert des paquets de petite taille car s’ils sont fragmentés, il faut s’assurer que leur contenu ne sera pas perdu) A. Branzan-Albu & D. Laurendeau GIF-66800

Le protocole UDP (3) UDP ou TCP? UDP peut sembler moins utile que TCP mais: Il est moins lourd que TCP Il demande moins de temps de traitement qu’une communication « stream » TCP Il n’y a aucune limitation sur le nombre de communication UDP qu’un OS peut traiter UDP est très bien adapté aux applications réseau à grande échelle A. Branzan-Albu & D. Laurendeau GIF-66800

Le protocole UDP (4) UDP ou TCP? (2) Par ailleurs: UDP demande à chaque hôte de traiter tous les paquets même s’ils ne lui sont pas destinés UDP peut causer des problèmes de sécurité car si les applications ne font pas la différence entre des paquets « valides » et des paquets « malicieux », des problèmes peuvent survenir Pour cette raison, les « firewalls » bloquent souvent les communications UDP d’atteindre certains hôtes sensibles. A. Branzan-Albu & D. Laurendeau GIF-66800

Broadcasting ou multicasting?
Les EV distribués comptent générale-ment plusieurs participants répartis plusieurs machines sur le réseau L’approche de broadcasting permet à la source de transmettre un même message à plusieurs destinations sur le réseau A. Branzan-Albu & D. Laurendeau GIF-66800

Broadcasting ou multicasting? (2)
Avec UDP/IP, les paquets ne sont transmis qu’aux hôtes qui lisent les paquets sur un port spécifique Cette approche est utile pour les petits EV distribués (sur un LAN) Un participant n’a pas à s’identifier, il n’a qu’à intercepter les paquets sur un port désigné pour l’application ou à transmettre lui-même de l’information A. Branzan-Albu & D. Laurendeau GIF-66800

En contrepartie, l’approche par broadcasting est inefficace car tous les hôtes doivent recevoir et traiter les paquets reçus même si aucune application n’est connectée sur le port. De plus, le broadcasting ne peut être utilisé pour les EV sur Internet (WAN) A. Branzan-Albu & D. Laurendeau GIF-66800

Pour « broadcaster », un hôte n’a qu’a générer un masque binaire qui détermine quels hôtes sur le réseau devraient recevoir le message. Par exemple pour transmettre un message à tous les ordinateurs connectés sur le réseau local , l’application n’a qu’à adresser le message de broadcast à l’adresse A. Branzan-Albu & D. Laurendeau GIF-66800

Le multicasting permet de pallier aux faiblesses du broadcasting pour les EV exploitant un WAN mais peut aussi être utilisé dans le contexte des EV sur un LAN A. Branzan-Albu & D. Laurendeau GIF-66800

Le multicasting utilise une stratégie de distribution « receiver-controlled » Cette stratégie s’inspire de celle d’un abonnement à un journal: Un message est acheminé à une liste pré-établie de distributeurs Les distributeurs recopient le message et le transmettent aux sous-distributeurs ou aux abonnés seulement A. Branzan-Albu & D. Laurendeau GIF-66800

Les adresses à sont désignées comme étant des adresses « multicast ». En général les EV utilisent des adresses dans les intervalles suivants: 226.*.*.* à 231.*.*.* 233.*.*.* à 238 .*.*.* A. Branzan-Albu & D. Laurendeau GIF-66800

Un transmetteur envoie un paquet à l’adresse multicast réservée à l’application Les récepteurs préalablement enregistrés reçoivent ces paquets des distributeurs A. Branzan-Albu & D. Laurendeau GIF-66800

La stratégie du multicasting est à comparer à celle du broadcasting qui s’inspire pour sa part de la distribution par courrier direct (de type publi-sac) qui est une stratégie de type « sender-controlled » (on continue à recevoir des paquets même si on ne le désire pas) A. Branzan-Albu & D. Laurendeau GIF-66800

Si une application nécessite une adresse IP multicast permanente, il faut en faire la demande à l’IANA Si une application à plus petite échelle ne requiert pas une adresse IP multicast permanente, elle peut en choisir une au hasard, mais en écoutant d’abord le Session Announcement Protocol (SAP) pour savoir quelles adresses IP multicast sont présentement utilisées A. Branzan-Albu & D. Laurendeau GIF-66800

Les messages SAP décrivent les sessions multicast actives, les messages SAP adoptent le protocole SDP (Session Description Protocol) Alternativement, le SDR (Session DiRectory Tool peut être utilisé pour surveiller les sessions multicast actives Après avoir choisi une adresse multicast inutilisée, l’application distribuée doit annoncer le choix de cette adresse A. Branzan-Albu & D. Laurendeau GIF-66800

Conclusion: Le multicasting émerge graduellement comme l’approche recommandée pour la construction d’EV distribués à grande échelle Cependant, comme cette technologie est encore jeune, les routeurs ne supportent pas tous le multicast A. Branzan-Albu & D. Laurendeau GIF-66800

Architectures de communication pour les EV distribués
Connexions logiques, connexions physiques et architectures de communication

Quelques définitions Connexion logique: illustre le parcours d’un message sur le chemin « logiciel » Connexion physique: illustre les liens physiques entre les participants A. Branzan-Albu & D. Laurendeau GIF-66800

Architecture client-serveur
Architecture logique A. Branzan-Albu & D. Laurendeau GIF-66800

Architecture client-serveur (2)
Architecture physique A. Branzan-Albu & D. Laurendeau GIF-66800

Architecture client-serveur (3)
Avantages Architecture simple Les serveurs peuvent décider des destinataires des messages Désavantages Le serveur est un goulot d’étranglement (solution: système à plusieurs serveurs eux-mêmes responsables de gérer plusieurs clients) Difficilement «scalables » A. Branzan-Albu & D. Laurendeau GIF-66800

Architecture peer-to-peer
Architecture logique A. Branzan-Albu & D. Laurendeau GIF-66800

Architecture peer-to-peer (2)
Architecture physique A. Branzan-Albu & D. Laurendeau GIF-66800

Architecture peer-to-peer (3)
Aucun serveur Chaque participant transmet les messages aux destinataires choisis Le broadcast peut être utilisé, mais cause un trafic élevé Le multicast est la meilleure solution dans ce cas Un logiciel de Area-Of-Interest-Management (AOIM) est nécessaire pour traiter les échanges EV plus « scalables », mais encore soumis aux limitations des routeurs supportant le multicast A. Branzan-Albu & D. Laurendeau GIF-66800

Le partage de l’état des acteurs dans un EV distribué
Serveur central, mise-à-jour régulière, prédiction

Introduction L’objectif principal d’un EV distribué est de donner aux utilisateurs l’illusion qu’ils partagent le même environnement Cet objectif peut être atteint si l’état dynamique des entités présentes dans l’environnement peut être partagé par tous les usagers A. Branzan-Albu & D. Laurendeau GIF-66800

Introduction (2) Ce partage d’état dynamique pose un problème de taille compte tenu des limitations imposées aux EV distribués par les réseaux Cette partie du cours s’intéresse aux approches qui peuvent être adoptées pour le partage de l’état dynamique des entités dans un EV distribué A. Branzan-Albu & D. Laurendeau GIF-66800

Etat dynamique partagé
Qu’est-ce que l’état d’une entité dans un EV? Position, orientation, vitesse des entités mobiles Forces auxquelles sont soumises les entités (gravité, frottement, etc.) Conditions météorologiques d’une simulation A. Branzan-Albu & D. Laurendeau GIF-66800

Etat dynamique partagé (2)
Idéalement, l’état d’une entité dans un EV distribué devrait être le même pour tous les utilisateurs de l’EV Or, la latence du réseau fait en sorte qu’il y a un délai entre le moment où l’état d’une entité est tranmis et celui où l’état est accessible aux utilisateurs A. Branzan-Albu & D. Laurendeau GIF-66800

Etat dynamique partagé (3)
Ce problème est connu sous le nom de « compromis cohérence-flot de données » (Consistency-Throughput Tradeoff) et s’énonce comme suit: «il est impossible de permettre un changement fréquent de l’état dynamique d’une entité dans un EV en garantissant que tous les participants puissent avoir accès instantanément et simultanément à une valeur identique de cet état » A. Branzan-Albu & D. Laurendeau GIF-66800

Démonstration du compromis
A. Branzan-Albu & D. Laurendeau GIF-66800

Implications du compronis
Caractéristique du système Cohérence absolue Taux de rafraichissement Cohérence de l’EV Identique pour tous les participants Déterminé par la capacité de recevoir les données par les machines dans l’EV Support de données dynamique Faible. Limitée par le protocole de cohérence Haut. Limité seulement par la bande passante Exigences sur l’infrastructure réseau Faible latence, haute fiabilité, variabilité réduite au minimum Réseau hétérogène possible Nombre de participants Faible Potentiellement élevé A. Branzan-Albu & D. Laurendeau GIF-66800

Solution au problème de partage d’état dynamique
Trois approches principales sont proposées au problème du partage de l’état dynamique des entités dans un EV distribué: Dépôts de données centraux (Central repositories) Prédiction (Dead-Reckoning) Mise-à-jour fréquente (Frequent State Regeneration) A. Branzan-Albu & D. Laurendeau GIF-66800

Dépôts centraux de données
3 2 n A. Branzan-Albu & D. Laurendeau GIF-66800

Dépôts centraux (2) Le dépôt peut résider: Sur le disque d’un serveur Capacité de stockage élevée Temps d’accès lent (peut être réduit si l’on utilise un dépôt « virtuel ») En mémoire Capacité de stockage plus réduite Temps d’accès plus rapide Possibilité de perte des données en cas de panne du serveur A. Branzan-Albu & D. Laurendeau GIF-66800

Dépôts centraux (3) A. Branzan-Albu & D. Laurendeau GIF-66800

Dépôts centraux (4) A. Branzan-Albu & D. Laurendeau GIF-66800

Dépôts centraux (5) Pour palier aux déficiences des systèmes basés sur les dépôts centraux il est possible de: Ne pas imposer que l’état des toutes les entités sont mis à jour fréquemment (par exemple les objets lointains ou l’arrière-scène) Cette approche peut s’implanter via un mécanisme « d’abonnement » à l’état d’une entité A. Branzan-Albu & D. Laurendeau GIF-66800

Dépôts centraux (6) Avantages Assurent une cohérente complète au prix d’un overhead de communication élevé Modèle simple du point de vue de l’implantation Un changement d’état sur une entité est immédiatement visible à tous les participants A. Branzan-Albu & D. Laurendeau GIF-66800

Mise-à-jour fréquente (1)
Avec cette approche les entités sont la propriété d’un hôte spécifique Cet hôte est responsable de transmettre le changement de l’état des entités pour lesquelles il détient la propriété Ce changement d ’état est « broadcasté » à l’aveuglette (i.e. sans acknowledgement) aux autres hôtes A. Branzan-Albu & D. Laurendeau GIF-66800

Les autres hôtes maintiennent une cache où résident une description de l’état de chaque entité de l’EV Lorsqu’un update est reçu, l’entité concernée voit son état rafraîchi dans la cache. A. Branzan-Albu & D. Laurendeau GIF-66800

La notion de propriété (ownership) est ici cruciale afin d’éviter que plusieurs hôtes ne tentent de mettre l’état d’une entité à jour Deux politiques peuvent être adoptées: Utilisation d’un lock manager pour attribuer la propriété avec un proxy updater Utilisation d’un transfert de propriété (encore via un lock manager) A. Branzan-Albu & D. Laurendeau GIF-66800

Mise-à-jour fréquente (4) (proxy)

Mise-à-jour fréquente (7) (transfert)

Avantages de l’approche avec mise-à-jour fréquente: Allège le traitement des changements d’état Permet de transformer une application à un seul hôte en une application à plusieurs hôtes (grâce au broadcasting) Comme la cohérence totale de l’EV n’est pas exigée, cela permet d’inclure plus d’entités dfans l’EV A. Branzan-Albu & D. Laurendeau GIF-66800

Désavantages de l’approche avec mise-à-jour fréquente: Le broadcasting des changements d’état exige une grande bande passante La latence du réseau cause des problèmes de réalisme (un tir sur un adversaire est rendu compliqué car ce dernier n’est jamais à l’endoit où il est sensé être selon l’affichage graphique… Le jitter cause aussi un problème de réalisme car, par exemple, la position d’un objet peut être mise à jour de manière irrégulière A. Branzan-Albu & D. Laurendeau GIF-66800

Prédiction (1) L’approche avec prédiction repose sur un modèle de l’état des entités qui est présent sur chaque hôte et qui est rafraîchi lors de la réception d’un update Entre les mises-à-jour, l’état de l’entité est prédit par le modèle Le défi consiste à concevoir des modèles précis mais abordables du point de vue du temps calcul de définir une stratégie de recalage des états lors de la réception des updates A. Branzan-Albu & D. Laurendeau GIF-66800

Prédiction (2) Une approche avec prédiction consiste donc en deux éléments principaux: Une technique de prédiction Une technique de convergence (pour recaler le modèle lors des updates) A. Branzan-Albu & D. Laurendeau GIF-66800

Prédiction (3) Définition de technique de prédiction: Modèle physique ou non de l’entité permettant de prédire son état en tout temps Le compromis précision du modèle et temps de calcul doit être fait afin que les EV puissent être suffisamment dynamiques tout en demeurant réalistes A. Branzan-Albu & D. Laurendeau GIF-66800

Prédiction (4) Techniques de prédiction utilisées Polynômes (d’ordre variable) Prédiction linéaire Prédiction avec des polynômes d’ordre 2 ou trois (complexité de calcul accrue) Modèles basés sur la physique ou dont le comportement suit une tendance connue (par exemple un objet qui se déplace sur une orbite elliptique) A. Branzan-Albu & D. Laurendeau GIF-66800

Prédiction (5) Techniques de convergence « snapping »: correction instantanée de l’état sans fusion entre l’état prédit et l’état réel contenu dans la mise-à-jour. Approche simple, mais peu réaliste sur le plan visuel Convergence linéaire: interpolation linéaire entre la position actuelle et la position réelle Convergence quadratique: interpolation du second degré entre la position actuelle et la position réelle A. Branzan-Albu & D. Laurendeau GIF-66800

Prédiction (6) Convergence par snapping A. Branzan-Albu & D. Laurendeau GIF-66800

Prédiction (7) Convergence linéaire A. Branzan-Albu & D. Laurendeau GIF-66800

Prédiction (8) Convergence quadratique (ou autre) A. Branzan-Albu & D. Laurendeau GIF-66800

Prédiction (9) Avantages de l’approche avec prédiction: Réduction de la bande passante Absence de serveur central Désavantages: Uniformité de l’état non garantie sur chaque hôte (car prédictions peuvent différer) Doit être adaptée à chaque application et n’est pas générique A. Branzan-Albu & D. Laurendeau GIF-66800

Conclusion Les EV distribués posent des défis importants aux concepteurs Les performances des réseaux sont très importantes quant au réalisme qui peut être atteint dans les EV distribués Aucune approche de mise-à-jour des états des entités présentes dans les EV n’est assez générale pour offrir une solution adéquate dans diverses applications différentes A. Branzan-Albu & D. Laurendeau GIF-66800

Environnements virtuels distribués

Présentations similaires

Présentation au sujet: "Environnements virtuels distribués"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Environnements virtuels distribués

Présentations similaires

Présentation au sujet: "Environnements virtuels distribués"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back