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

Présentation au sujet: "1 Environnements virtuels distribués A. Branzan-Albu et D. Laurendeau Dép. de génie électrique et de génie informatique Université Laval."— Transcription de la présentation:

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

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

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

4 4 Caractéristiques recherchées Un EV distribué devrait offrir aux utilisateurs: partagel’espace virtuel 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 présence 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 partage Un sens de partage du temps: un utilisateur devrait percevoir les événements survenant dans l’EV en même temps que les autres moyens de communication Un ou des moyens de communication par exemple via des interfaces haptiques, visuelles ou graphiques partagerd’interagirréaliste avec les objets du monde virtuel et avec 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

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

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

7 7 Défis posés aux EV distribués (3) Les EV distribués limites de bande passantetype de connexion Doivent tenir compte des limites de bande passante sur le réseau et du type de connexion des utilisateurs (haute vitesse, modem, etc.) temps réel 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

8 8 Défis posés aux EV distribués (4) Les EV distribués panned’interruption Doivent prévoir les cas de panne et d’interruption de fonctionnement Arrêt Arrêt du système: peut causer la perte des résultats d’une simulation Fermeture Fermeture du système: peut interrompre l’accès à de nouveaux utilisateurs sans perturber les utilisateurs existants Dégradation Dégradation du système: quelques composantes d’un système peuvent fonctionner de manière sous-optimale sans interrompre la simulation

9 9 Défis posés aux EV distribués (5) Les EV distribués scalés Doivent pouvoir être « scalés » pour permettre une croissance dans les simulations Nombre d’entités Nombre d’utilisateurs complexité La « scalabilité » a une complexité qui croît de manière exponentielle avec le nombre d’entités qui peuvent interagir entre elles

10 10 Défis posés aux EV distribués (6) Les EV distribués déployésconfigurés Doivent pouvoir être déployés et configurés facilement, spécialement pour ceux faisant appel à l’Internet

11 11 Communications réseau Notions et concepts de base

12 12 Notion de réseau mediumdonnées d’informationhôtes expérience virtuelle partagée 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

13 13 Notions fondamentales de transfert de données (1) Latence de réseau 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: réalisme Le réalisme d’une expérience virtuelle Les concepteurs d’EV ne peuvent rien contre la latence

14 14 Latence du réseau (2) Origines de la latence: Limites physiques 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 Délais de traitement par les ordinateurs hôtes causés par le hardware et le software

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

16 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

17 17 Notions fondamentales de transfert de données (2) Bande passante 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)

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

19 19 Notions fondamentales de transfert de données (3) Distinction Distinction entre latence et bande passante: Bande passante Bande passante: nombre de bits par seconde qui peuvent passer dans un medium (si on les regardait passer) Latence Latence: délai du transfert, soit le temps nécessaire au transfert d’un bit d’un point à un autre

20 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

21 21 Notions fondamentales de transfert de données (4) Fiabilité du réseau Fiabilité du réseau: quantité perdues Mesure qui donne les performances du réseau quant à la quantité des données qui sont perdues entre la source et la destination

22 22 Fiabilité du réseau (2) 2 catégories de défaillances du réseau: dropping jamais « 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 inutilisables « corruption »: les données se rendent de la source à la destination, mais sont inutilisables car elles ont été modifiées durant leur trajet

23 23 Fiabilité du réseau (3) Causesprincipales Causes principales du manque de fiabilité: Mauvaises connexions Mauvaises connexions (rare): 1 bit/10 10 sur les réseaux câblés. Cette performance est plus réduite sur les réseaux sans fil. Routeurs de réseaux quantités trop importantes de données ressources de calcul 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.

24 24 Fiabilité du réseau (4) Méthodes Méthodes utilisées pour augmenter la fiabilité du réseau: checksums 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. protocole acknowledge 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.

25 25 Notions fondamentales de transfert de données (5) Protocoles réseau Protocoles réseau règles Un protocole est un ensemble de règles que deux applications respectent pour communiquer entre elles

26 26 Protocoles réseau Un protocole repose sur: format de paquets Un format de paquets de données qui décrit à quoi les données ressemblent sémantique de paquets Une sémantique de paquets qui décrit comment les paquets sont structurés politique de traitement des erreurs Une politique de traitement des erreurs

27 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 28 Communications réseau socketsBSD L’architecture des sockets BSD

29 29 Les sockets BSD sockets BSD application 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éments principaux: L’architecture des sockets BSD repose sur deux éléments principaux: sockets Les sockets ports Les ports

30 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

31 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 incluant 1. Le type de protocole 2. 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

32 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

33 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

34 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

35 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.

36 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

37 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

38 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?

39 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

40 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)

41 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 42 Le protocole IP (Internet Protocol) Notions de base

43 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

44 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 45 Les protocoles Internet pour les EV distribués TCP, UDP, Multicasting et Broadcasting

46 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

47 47 Le protocole TCP (2) TCP/IP donne l’impression à une application qu’elle entretient une communication point-à-point avec une autre application

48 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

49 49 Le protocole UDP User Datagram Protocol (UDP) est un protocole léger pour la communication entre applications

50 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)

51 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

52 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.

53 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

54 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

55 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)

56 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

57 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

58 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

59 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.*.*.*

60 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

61 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)

62 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

63 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

64 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 65 Architectures de communication pour les EV distribués Connexions logiques, connexions physiques et architectures de communication

66 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

67 67 Architecture client-serveur Architecture logique

68 68 Architecture client-serveur (2) Architecture physique

69 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 »

70 70 Architecture peer-to-peer Architecture logique

71 71 Architecture peer-to-peer (2) Architecture physique

72 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 73 Le partage de l’état des acteurs dans un EV distribué Serveur central, mise-à-jour régulière, prédiction

74 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

75 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é

76 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

77 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

78 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 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 »

79 79 Démonstration du compromis

80 80 Implications du compronis Caractéristique du système Cohérence absolueTaux de rafraichissement Cohérence de l’EVIdentique 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 participantsFaiblePotentiellement élevé

81 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)

82 82 Dépôts centraux de données 2 3 n

83 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

84 84 Dépôts centraux (3)

85 85 Dépôts centraux (4)

86 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é

87 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

88 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

89 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.

90 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)

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

92 92 Mise-à-jour fréquente (5) (proxy)

93 93 Mise-à-jour fréquente (6) (proxy)

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

95 95 Mise-à-jour fréquente (8) (transfert)

96 96 Mise-à-jour fréquente (9) (transfert)

97 97 Mise-à-jour fréquente (10) Avantages de l’approche avec mise-à-jour fréquente: 1. Allège le traitement des changements d’état 2. 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

98 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 passante 2. 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

99 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 calcul 2. de définir une stratégie de recalage des états lors de la réception des updates

100 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)

101 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

102 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)

103 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

104 104 Prédiction (6) Convergence par snapping

105 105 Prédiction (7) Convergence linéaire

106 106 Prédiction (8) Convergence quadratique (ou autre)

107 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

108 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