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

Environnements
virtuels distribués
A. Branzan-Albu et D. Laurendeau
Dép. de génie électrique
et de génie informatique
Université Laval
1
Introduction
Définition, caractéristiques et défis
posés aux environnements virtuels
répartis
2
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
3
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
4
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.)
5
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.
6
Défis posés aux EV distribués

(3)
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
7
Défis posés aux EV distribués

(4)
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
8
Défis posés aux EV distribués

(5)
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
nb entités
2
9
Défis posés aux EV distribués

Les EV distribués

Doivent pouvoir être déployés et configurés facilement,
spécialement pour ceux faisant appel à l’Internet
10
(6)
Communications réseau
Notions et concepts de base
11
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
12
Notions fondamentales de transfert de données


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:


(1)
Le réalisme d’une expérience virtuelle
Les concepteurs d’EV ne peuvent rien
contre la latence
13
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
14
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.
15
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
16
Notions fondamentales de transfert de données


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)
17
(2)
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 ellemême est de 64 Kbps)
Ethernet: 10 Mbps, 100 Mbps, 1 Gbps
Fibres optiques modernes: 10 Gbps
A. Branzan-Albu & D. Laurendeau
18
Notions fondamentales de transfert de données

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
19
(3)
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
20
Notions fondamentales de transfert de données

(4)
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
21
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
22
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.
23
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.
24
Notions fondamentales de transfert de données

Protocoles réseau

Un protocole est un ensemble de règles
que deux applications respectent pour
communiquer entre elles
25
(5)
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
26
Protocoles réseau (2)


Il existe des milliers de protocoles
réseau
Les machines utilisent souvent plusieurs
protocoles pour accomplir diverses
tâches
27
Communications réseau
L’architecture des sockets BSD
28
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
29
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
30
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
1.
2.
3.
4.
5.
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
31
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
32
Les sockets BSD (4)
Un socket identifie au moins les 5 types
d’information suivants sur un canal de
communication:

1.
2.
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
33
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
34
Les sockets BSD (5)
4.
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
35
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
36
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
37
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
38
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
39
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
40
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
A. Branzan-Albu & D. Laurendeau
41
Le protocole IP (Internet
Protocol)
Notions de base
42
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
43
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 (TimeTo-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
44
Les protocoles Internet pour
les EV distribués
TCP, UDP, Multicasting et
Broadcasting
45
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
46
Le protocole TCP (2)

TCP/IP donne l’impression à une
application qu’elle entretient une
communication point-à-point avec une
autre application
47
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
48
Le protocole UDP

User Datagram Protocol (UDP) est un
protocole léger pour la communication
entre applications
49
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)
50
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
51
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.
52
Broadcasting ou multicasting?


Les EV distribués comptent généralement 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
53
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
54
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)
55
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
56
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
57
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
58
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 .*.*.*
59
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
60
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 « sendercontrolled » (on continue à recevoir des
paquets même si on ne le désire pas)
61
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
62
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
63
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
64
Architectures de communication pour
les EV distribués
Connexions logiques, connexions
physiques et architectures de
communication
65
Quelques définitions


Connexion logique: illustre le parcours
d’un message sur le chemin « logiciel »
Connexion physique: illustre les liens
physiques entre les participants
66
Architecture client-serveur
Architecture logique
S e rve u r
C lie n t
C lie n t
C lie n t
67
Architecture client-serveur (2)
Architecture physique
S e rve u r
C lie n t
C lie n t
E th e rn e t
C lie n t
68
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 »
69
Architecture peer-to-peer
Architecture logique
A O IM 1
A O IM 2
A O IM n
Jo u e u r 1
Jo u e u r 2
Jo u e u r n
70
Architecture peer-to-peer (2)
S e rve u r
C lie n t
C lie n t
E th e rn e t
Architecture physique
C lie n t
71
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
72
Le partage de l’état des
acteurs dans un EV distribué
Serveur central, mise-à-jour
régulière, prédiction
73
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
74
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é
75
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
76
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
77
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 »
78
Démonstration du compromis
M a ch in e 1
M a ch in e 2
Je su is à
(1 0 ,2 0 )
 t
Il e st à
(1 0 ,2 0 )
 t
O K tu e s à
(1 0 ,2 0 )
Je su is à
(1 5 ,2 5 )
79
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é
80
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)
81
Dépôts centraux de données
up
Utilisateur 1
Re
da
te
Up
da
te
Re
ad
ad
Utilisateur 13
Dépôt
central
Etat
Entité 1
Up
Utilisateur 12
da
te
Re
ad
Etat
Entité n
Up
Re
da
te
ad
Utilisateur 1n
82
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
83
Dépôts centraux (3)
84
Dépôts centraux (4)
host1 : Host
AServer :
Server
anEntity :
Entity
entityState :
State
changeEntity(State, Entity)
lockEntity( )
setChange(State)
changeState(State)
unLockEntity( )
acknowledgeChange( )
85
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é
86
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
87
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
88
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.
89
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)
90
Mise-à-jour fréquente (4)
(proxy)
91
Mise-à-jour fréquente (5)
aFirstHost :
HostFSR
aSecondHost :
HostFSR
aLockServer :
LockServerFSR
(proxy)
anEntity :
EntityFSR
LockRequest()
LockGranted( )
LockRequest()
LockNotGranted( )
ChangeState(StateFSR)
BroadcastStateChange(EntityFSR)
AskForChange(EntityFSR, StateFSR)
ChangeState(StateFSR)
BroadcastStateChange(EntityFSR)
LockRealease( )
92
Mise-à-jour fréquente (6)
(proxy)
L o ck M a n a g e r
L o ck
E n t. 1
É ta p e
1
st 1
u e tité
q
e
n
E
R
ck
ck
o
Lo
L
e
1
d
o r it é
cc nt
A
E
L o ck
E n t. 2
É ta p e
2
H o st 1
H o st 2
É ta p e
3
C a ch e
E ta t
e n tité 1
C a ch e
E ta t
e n tité 2
U p d a te S ta te
E n tité 1
E ta t
e n tité 1
E ta t
e n tité 2
93
Mise-à-jour fréquente (7)
(transfert)
94
Mise-à-jour fréquente (8)
aHost1 :
HostFSR
anEntity :
EntityFSR
aHost2 :
HostFSR
(transfert)
aLockServer :
LockServerFSR
ChangeState(StateFSR)
AskOwnership( )
GrantOnwership( )
NotifyLockTransfer( )
AcknowledgeLockTransfer( )
ChangeState(StateFSR)
95
Mise-à-jour fréquente (9)
(transfert)
L o ck M a n a g e r
3
N
ot
i
a
fic
n
tio
Tr
a
f
ns
er
t
L
k
oc
E
n
é
tit
1
L o ck
E n t. 1
L o ck
E n t. 2
ck é
L o rm
i
rt
e
nf
sf co
an 1
r
T it é
nt
E
4
H o st 1
H o st 2
1
U p d a te S ta te E n tité 1
2
R e q u e st o w n e rsh ip E n tité 1
5
A cco rd e r o w n e rsh ip E n tité 1
C a ch e
E ta t
e n tité 1
E ta t
e n tité 2
6
U p d a te S ta te E n tité 1
C a ch e
E ta t
e n tité 1
E ta t
e n tité 2
96
Mise-à-jour fréquente (10)
Avantages de l’approche avec mise-à-jour
fréquente:

1.
2.
3.
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
97
Mise-à-jour fréquente (11)
Désavantages de l’approche avec mise-àjour fréquente:

1.
2.
3.
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
98
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.
2.
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
99
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)
100
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
101
Prédiction (4)

Techniques de prédiction utilisées
1.
Polynômes (d’ordre variable)


2.
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)
102
Prédiction (5)
Techniques de convergence

1.
2.
3.
« 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
103
Prédiction (6)
Convergence par snapping
N o u ve lle tra je cto ire
S n a p p in g
T ra je cto ire p ré d ite
104
Prédiction (7)
Convergence linéaire
N o u ve lle tra je cto ire
C on
in .
v. L
U p d a te
T ra je cto ire p ré d ite
105
Prédiction (8)
Convergence quadratique (ou autre)
N o u ve lle tra je cto ire
C o n v. Q u a d .
U p d a te
T ra je cto ire p ré d ite
106
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
107
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
108