1 environnements virtuels distribués a. branzan-albu et d. laurendeau dép. de génie électrique...
TRANSCRIPT
1
Environnements virtuels distribués
A. Branzan-Albu et D. Laurendeau
Dép. de génie électriqueet de génie informatique
Université Laval
2
Introduction
Définition, caractéristiques et défis posés aux
environnements virtuels répartis
A. Branzan-Albu & D. Laurendeau GIF-66800 3
Qu’est-ce qu’un EV distribué? C’est un environnement virtuel:
Où plusieurs utilisateursplusieurs utilisateurs peuvent interagirinteragir en temps réeltemps réel même si ces utilisateurs sont situés à des lieux physiques lieux physiques différentsdifférents
Qui permet aux utilisateurs de percevoirpercevoir les informations visuellesvisuelles en trois trois dimensionsdimensions
Qui permet aux utilisateurs de percevoirpercevoir les informations sonoressonores en stéréostéréo
A. Branzan-Albu & D. Laurendeau GIF-66800 4
Caractéristiques recherchées Un EV distribué devrait offrir aux utilisateurs:
Un sens de partagepartage de l’espace virtuell’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ésencepré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 partagepartage 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 communicationmoyens de communication par exemple via des interfaces haptiques, visuelles ou graphiques
Un ou des moyens de partagerpartager et d’interagird’interagir de manière réaliste réaliste avec les objets du monde virtuel et avecavec les objets du monde virtuel et avec l’environnement lui-même
A. Branzan-Albu & D. Laurendeau GIF-66800 5
Défis posés aux EV distribués Les EV distribués
Sont soumis aux contraintes du réseaucontraintes du réseau: délais, collisions, jitter, pertes de communication, partage des ressources de bande passante;
Doivent assurer des performances d’affichage performances d’affichage graphique acceptablesgraphique acceptables afin que l’évolution du monde virtuel soit réaliste et perceptuellement correcte
Doivent assurer un niveau acceptable d’interactivité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 6
Défis posés aux EV distribués (2)
Les EV distribués Doivent intégrer des bases de donnéesbases de données sur
les propriétés du monde et de ses composantes
Doivent éventuellement permettre d’identifier les participantsd’identifier les participants (« user authentification »)
Doivent permettre de stockerstocker l’évolution du monde à un moment donné afin de le réactiverréactiver plus tard.
A. Branzan-Albu & D. Laurendeau GIF-66800 7
Défis posés aux EV distribués (3)
Les EV distribués Doivent tenir compte des limites de bande limites de bande
passantepassante sur le réseau et du type de connexiontype de connexion des utilisateurs (haute vitesse, modem, etc.)
Doivent assurer un fonctionnement en temps temps réelré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 8
Défis posés aux EV distribués (4)
Les EV distribués Doivent prévoir les cas de pannepanne et
d’interruptiond’interruption de fonctionnement ArrêtArrêt du système: peut causer la perte des
résultats d’une simulation FermetureFermeture du système: peut interrompre l’accès à
de nouveaux utilisateurs sans perturber les utilisateurs existants
DégradationDé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 9
Défis posés aux EV distribués (5)
Les EV distribués Doivent pouvoir être « scalésscalés » pour permettre une
croissance dans les simulations Nombre d’entités Nombre d’utilisateurs
La « scalabilité » a une complexitécomplexité qui croît de manière exponentielle avec le nombre d’entités qui peuvent interagir entre elles
entitésnb2
A. Branzan-Albu & D. Laurendeau GIF-66800 10
Défis posés aux EV distribués (6)
Les EV distribués
Doivent pouvoir être déployésdéployés et configurésconfigurés facilement, spécialement pour ceux faisant appel à l’Internet
11
Communications réseau
Notions et concepts de base
A. Branzan-Albu & D. Laurendeau GIF-66800 12
Notion de réseau Définition de réseau en EV
distribués: mediummedium pour l’échange de donnéesdonnées et d’informationd’information entre plusieurs hôteshôtes participant à une expérience expérience virtuelle partagéevirtuelle partagée
A. Branzan-Albu & D. Laurendeau GIF-66800 13
Notions fondamentales de transfert de données (1)
Latence de réseauLatence 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éalismeréalisme d’une expérience virtuelle
Les concepteurs d’EV ne peuvent rien contre la latence
A. Branzan-Albu & D. Laurendeau GIF-66800 14
Latence du réseau (2)
Origines de la latence: Limites physiquesLimites 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 traitementDélais de traitement par les ordinateurs hôtes causés par le hardware et le software
A. Branzan-Albu & D. Laurendeau GIF-66800 15
Latence du réseau (3)
Origines de la latence (2): Délais dans le réseauDé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 16
Latence du réseau (4)
Ordre de grandeur des délais de latence: Variable:
Ethernet (LAN): 10 ms Modem: 100 ms Ethernet (WAN)
Transcontinental: 60-150 ms Intercontinental: 250-500 ms
A. Branzan-Albu & D. Laurendeau GIF-66800 17
Notions fondamentales de transfert de données (2)
Bande passanteBande 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 18
Bande passante (2)
La bande passante est aussi limitée par le hardware de transmission ModemModem: 14 Kbps à 56 Kbps/s (limite
physique de la ligne téléphonique elle-même est de 64 Kbps)
EthernetEthernet: 10 Mbps, 100 Mbps, 1 Gbps Fibres optiquesFibres optiques modernes: 10 Gbps
A. Branzan-Albu & D. Laurendeau GIF-66800 19
Notions fondamentales de transfert de données (3)
DistinctionDistinction entre latence et bande passante: Bande passanteBande passante: nombre de bits par
seconde qui peuvent passer dans un medium (si on les regardait passer)
LatenceLatence: 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 20
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 21
Notions fondamentales de transfert de données (4)
Fiabilité du réseauFiabilité du réseau: Mesure qui donne les performances
du réseau quant à la quantitéquantité des données qui sont perduesperdues entre la source et la destination
A. Branzan-Albu & D. Laurendeau GIF-66800 22
Fiabilité du réseau (2)
2 catégories de défaillances du réseau: « droppingdropping »: les données émises par
la source n’atteignent jamaisjamais la destination parce qu’elles ont été détruites par le réseau
« corruptioncorruption »: les données se rendent de la source à la destination, mais sont inutilisablesinutilisables car elles ont été modifiées durant leur trajet
A. Branzan-Albu & D. Laurendeau GIF-66800 23
Fiabilité du réseau (3)
CausesCauses principalesprincipales du manque de fiabilité: Mauvaises connexionsMauvaises 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éseauxRouteurs de réseaux: les erreurs sont particulièrement causées par des quantités quantités trop importantes de donnéestrop importantes de données à traiter par rapport aux ressources de calculressources 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 24
Fiabilité du réseau (4)
MéthodesMéthodes utilisées pour augmenter la fiabilité du réseau: Utilisation de « checksumschecksums » 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 protocoleprotocole basé sur un « accusé de réception » (acknowledgeacknowledge): 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 25
Notions fondamentales de transfert de données (5)
Protocoles réseauProtocoles réseau Un protocole est un ensemble de
règlesrègles que deux applications respectent pour communiquer entre elles
A. Branzan-Albu & D. Laurendeau GIF-66800 26
Protocoles réseau
Un protocole repose sur: Un format de paquetsformat de paquets de données qui
décrit à quoi les données ressemblent Une sémantique de paquetssémantique de paquets qui décrit
comment les paquets sont structurés Une politique de traitement des politique de traitement des
erreurserreurs
A. Branzan-Albu & D. Laurendeau GIF-66800 27
Protocoles réseau (2)
Il existe des milliers de protocoles réseau
Les machines utilisent souvent plusieurs protocoles pour accomplir diverses tâches
28
Communications réseau
L’architecture des socketssockets BSDBSD
A. Branzan-Albu & D. Laurendeau GIF-66800 29
Les sockets BSD L’architecture des sockets BSDsockets BSD permet
aux machines qui envoient et recoivent des paquets de données de décider à quelle applicationapplication ces paquets sont destinés
L’architecture des sockets BSD repose sur deux éléments principaux:éléments principaux: Les sockets sockets Les portsports
A. Branzan-Albu & D. Laurendeau GIF-66800 30
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 31
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 incluant1. Le type de protocole2. L’adresse de l’ordinateur hôte (réception)3. Le numéro de port de l’application (réception)4. L’adresse de l’ordinateur source (transmission)5. Le port de l’application d’envoi
A. Branzan-Albu & D. Laurendeau GIF-66800 32
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 33
Les sockets BSD (4) Un socket identifie au moins les 5
types d’information suivants sur un canal de communication:
1. Le protocole: comment le système d’exploitation gère l’échange d’information (avec acknowledge ou non, etc.)
2. 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 34
Les sockets BSD (5)3. 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 35
Les sockets BSD (5)4. 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
5. 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 36
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 65536 ports. Les systèmes d’exploitation peuvent donc supporter plusieurs applications simultanément
A. Branzan-Albu & D. Laurendeau GIF-66800 37
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 38
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 39
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 à 49151 sont enregistrés pour être utilisés par des protocoles bien connus
A. Branzan-Albu & D. Laurendeau GIF-66800 40
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 41
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 49152 et 65532
Si une application devient populaire, il est préférable de demander un numéro enregistré à l’IANA
42
Le protocole IP (Internet Protocol)
Notions de baseNotions de base
A. Branzan-Albu & D. Laurendeau GIF-66800 43
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 44
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
45
Les protocoles Internet pour les EV distribués
TCP, UDP, Multicasting et TCP, UDP, Multicasting et BroadcastingBroadcasting
A. Branzan-Albu & D. Laurendeau GIF-66800 46
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 47
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 48
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 49
Le protocole UDP User Datagram Protocol (UDP) est
un protocole léger pour la communication entre applications
A. Branzan-Albu & D. Laurendeau GIF-66800 50
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 51
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 52
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 53
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 54
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 55
Broadcasting ou multicasting? (3) 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 56
Broadcasting ou multicasting? (4) 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 10.25.12, l’application n’a qu’à adresser le message de broadcast à l’adresse 10.25.12.255
A. Branzan-Albu & D. Laurendeau GIF-66800 57
Broadcasting ou multicasting? (5)
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 58
Broadcasting ou multicasting? (6) 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 59
Broadcasting ou multicasting? (7)
Les adresses 224.0.0.0 à 239.255.255.255 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 60
Broadcasting ou multicasting? (7)
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 61
Broadcasting ou multicasting? (8)
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 62
Broadcasting ou multicasting? (9) 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 63
Broadcasting ou multicasting? (10)
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 64
Broadcasting ou multicasting? (11)
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
65
Architectures de communication pour les EV distribués
Connexions logiques, Connexions logiques, connexions physiques et connexions physiques et
architectures de architectures de communicationcommunication
A. Branzan-Albu & D. Laurendeau GIF-66800 66
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 67
Architecture client-serveur
Serveur
Client Client Client
Architecture logique
A. Branzan-Albu & D. Laurendeau GIF-66800 68
Architecture client-serveur (2)
Architecture physique
Ethernet
Serveur
Client
Client Client
A. Branzan-Albu & D. Laurendeau GIF-66800 69
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 70
Architecture peer-to-peer
Architecture logique
AOIM 1 AOIM 2 AOIM n
Joueur 1 Joueur 2 Joueur n
A. Branzan-Albu & D. Laurendeau GIF-66800 71
Architecture peer-to-peer (2)
Ethernet
Serveur
Client
Client Client
Architecture physique
A. Branzan-Albu & D. Laurendeau GIF-66800 72
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
73
Le partage de l’état des acteurs dans un EV distribué
Serveur central, mise-à-jour Serveur central, mise-à-jour régulière, prédictionrégulière, prédiction
A. Branzan-Albu & D. Laurendeau GIF-66800 74
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 75
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 76
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 77
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 78
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 «il est impossible de permettre un changement fréquent de l’état dynamique d’une entité dans fréquent de l’état dynamique d’une entité dans un EV en garantissant que tous les participants un EV en garantissant que tous les participants
puissent avoir accès instantanément et puissent avoir accès instantanément et simultanément à une valeur identique de cet simultanément à une valeur identique de cet
état »état »
A. Branzan-Albu & D. Laurendeau GIF-66800 79
Démonstration du compromis
Je suis à(10,20)
Machine 1 Machine 2
t
Il est à(10,20)
OK tu es à(10,20)
t
Je suis à(15,25)
A. Branzan-Albu & D. Laurendeau GIF-66800 80
Implications du compronisCaractéristique
du systèmeCohérence
absolueTaux 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 81
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 82
Dépôts centraux de données
Dépôtcentral
EtatEntité n
Utilisateur 1 Utilisateur 1
Utilisateur 1Utilisateur 1
EtatEntité 1
2
3
n
A. Branzan-Albu & D. Laurendeau GIF-66800 83
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 84
Dépôts centraux (3)
Server
changeEntity()acknowledgeChangeEntity()
State
changeState()
Host
acknowledgeChange()
11
connects to
1..n1..n
serves
Entity
lockEntity()unLockEntity()setChange()
0..n0..n
11
have a
A. Branzan-Albu & D. Laurendeau GIF-66800 85
Dépôts centraux (4)host1 : Host AServer :
ServeranEntity :
EntityentityState :
State
changeEntity(State, Entity)
lockEntity( )
setChange(State)
changeState(State)
unLockEntity( )
acknowledgeChange( )
A. Branzan-Albu & D. Laurendeau GIF-66800 86
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 87
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 88
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 89
Mise-à-jour fréquente (2) 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 90
Mise-à-jour fréquente (3) 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 91
Mise-à-jour fréquente (4) (proxy)
LockServerFSR
LockRequest()LockRealease()
EntityFSR
ChangeState()ReadState()
StateFSR
ChangeState()ReadState()
11
have a
HostFSR
LockGranted()BroadcastStateChange()LockNotGranted()AskForChange()
0..n0..n
owns
1..n1..n
A. Branzan-Albu & D. Laurendeau GIF-66800 92
Mise-à-jour fréquente (5) (proxy)
aFirstHost : HostFSR
aSecondHost : HostFSR
aLockServer : LockServerFSR
anEntity : EntityFSR
LockRequest()
LockGranted( )
LockRequest()
LockNotGranted( )
ChangeState(StateFSR)
BroadcastStateChange(EntityFSR)
AskForChange(EntityFSR, StateFSR)
ChangeState(StateFSR)
BroadcastStateChange(EntityFSR)
LockRealease( )
A. Branzan-Albu & D. Laurendeau GIF-66800 93
Mise-à-jour fréquente (6) (proxy)
Host 1
Cache
Etatentité 1
Etatentité 2
Host 2
Cache
Etatentité 1
Etatentité 2
Lock Manager
LockEnt. 2
LockEnt. 1
Update StateEntité 1
Request
Lock
Enti
té 1
Accord
e Lock
Entité 1
Étape1
Étape2
Étape3
A. Branzan-Albu & D. Laurendeau GIF-66800 94
Mise-à-jour fréquente (7) (transfert)
EntityFSR
ChangeState()ReadState()
StateFSR
ChangeState()ReadState()
11
have a
LockServerFSR
LockRequest()LockRelease()NotifyLockTransfer()
HostFSR
LockGranted()BroadcastStateChange()LockNotGranted()AskForChange()AskOwnership()GrantOnwership()AcknowledgeLockTransfer()
0..n0..n
owns
1..n1..n
A. Branzan-Albu & D. Laurendeau GIF-66800 95
Mise-à-jour fréquente (8) (transfert)
aHost1 : HostFSR
anEntity : EntityFSR
aHost2 : HostFSR
aLockServer : LockServerFSR
ChangeState(StateFSR)
AskOwnership( )
GrantOnwership( )
NotifyLockTransfer( )
AcknowledgeLockTransfer( )
ChangeState(StateFSR)
A. Branzan-Albu & D. Laurendeau GIF-66800 96
Mise-à-jour fréquente (9) (transfert)
1Update State Entité 1
3
Notific
ation T
rans
fert
Lock
Ent
ité 1
4
Transfe
rt Lock
Entité 1 co
nfirmé
Lock Manager
LockEnt. 2
LockEnt. 1
Host 1
Cache
Etatentité 1
Etatentité 2
Host 2
Cache
Etatentité 1
Etatentité 2
2Request ownership Entité 1
5Accorder ownership Entité 1
6Update State Entité 1
A. Branzan-Albu & D. Laurendeau GIF-66800 97
Mise-à-jour fréquente (10) Avantages de l’approche avec mise-à-
jour fréquente:1. Allège le traitement des changements
d’état2. Permet de transformer une application à
un seul hôte en une application à plusieurs hôtes (grâce au broadcasting)
3. 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 98
Mise-à-jour fréquente (11) Désavantages de l’approche avec mise-
à-jour fréquente:1. Le broadcasting des changements d’état
exige une grande bande passante2. 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…
3. 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 99
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 à1. concevoir des modèles précis mais abordables du
point de vue du temps calcul2. de définir une stratégie de recalage des états lors de
la réception des updates
A. Branzan-Albu & D. Laurendeau GIF-66800 100
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 101
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 102
Prédiction (4) Techniques de prédiction utilisées
1. Polynômes (d’ordre variable) Prédiction linéaire Prédiction avec des polynômes d’ordre
2 ou trois (complexité de calcul accrue)
2. 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 103
Prédiction (5) Techniques de convergence
1. « 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
2. Convergence linéaire: interpolation linéaire entre la position actuelle et la position réelle
3. Convergence quadratique: interpolation du second degré entre la position actuelle et la position réelle
A. Branzan-Albu & D. Laurendeau GIF-66800 104
Prédiction (6)
Trajectoire prédite
Nouvelle trajectoire
Snapping
Convergence par snapping
A. Branzan-Albu & D. Laurendeau GIF-66800 105
Prédiction (7)
Convergence linéaire
Trajectoire prédite
Nouvelle trajectoire
Conv. Lin.
Update
A. Branzan-Albu & D. Laurendeau GIF-66800 106
Prédiction (8)
Convergence quadratique (ou autre)
Trajectoire prédite
Nouvelle trajectoire
Update
Conv. Quad.
A. Branzan-Albu & D. Laurendeau GIF-66800 107
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 108
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