La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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ésentations similaires


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 A. Branzan-Albu & D. Laurendeau GIF Quest-ce quun EV distribué? Cest 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 A. Branzan-Albu & D. Laurendeau GIF Caractéristiques recherchées Un EV distribué devrait offrir aux utilisateurs: partagelespace virtuel Un sens de partage de lespace virtuel (« shared sense of space ») i.e. un participant a limpression dêtre dans le même lieux physique que les autres présence Un sens de présence: un utilisateur occupe lenvironnement 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 lEV 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 partagerdinteragirréaliste avec les objets du monde virtuel et avec Un ou des moyens de partager et dinteragir de manière réaliste avec les objets du monde virtuel et avec lenvironnement lui-même

5 A. Branzan-Albu & D. Laurendeau GIF 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 daffichage graphique acceptables Doivent assurer des performances daffichage graphique acceptables afin que lévolution du monde virtuel soit réaliste et perceptuellement correcte dinteractivité Doivent assurer un niveau acceptable dinteractivité en temps réel (input en temps réel des utilisateurs pour modifier le monde, etc.)

6 A. Branzan-Albu & D. Laurendeau GIF 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 didentifier les participants Doivent éventuellement permettre didentifier 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 A. Branzan-Albu & D. Laurendeau GIF 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 A. Branzan-Albu & D. Laurendeau GIF Défis posés aux EV distribués (4) Les EV distribués pannedinterruption Doivent prévoir les cas de panne et dinterruption de fonctionnement Arrêt Arrêt du système: peut causer la perte des résultats dune simulation Fermeture Fermeture du système: peut interrompre laccès à de nouveaux utilisateurs sans perturber les utilisateurs existants Dégradation Dégradation du système: quelques composantes dun système peuvent fonctionner de manière sous-optimale sans interrompre la simulation

9 A. Branzan-Albu & D. Laurendeau GIF 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 dentités Nombre dutilisateurs complexité La « scalabilité » a une complexité qui croît de manière exponentielle avec le nombre dentités qui peuvent interagir entre elles

10 A. Branzan-Albu & D. Laurendeau GIF 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 à lInternet

11 11 Communications réseau Notions et concepts de base

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

13 A. Branzan-Albu & D. Laurendeau GIF 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 dun point à un autre La latence a un impact direct sur: réalisme Le réalisme dune expérience virtuelle Les concepteurs dEV ne peuvent rien contre la latence

14 A. Branzan-Albu & D. Laurendeau GIF 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 latlantique 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 A. Branzan-Albu & D. Laurendeau GIF 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 linstrumentation réseau: routeurs, commutateurs, etc.

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

17 A. Branzan-Albu & D. Laurendeau GIF 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 lordinateur source et lordinateur 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 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 A. Branzan-Albu & D. Laurendeau GIF 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 dun bit dun point à un autre

20 A. Branzan-Albu & D. Laurendeau GIF 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 A. Branzan-Albu & D. Laurendeau GIF 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 A. Branzan-Albu & D. Laurendeau GIF Fiabilité du réseau (2) 2 catégories de défaillances du réseau: dropping jamais « dropping »: les données émises par la source natteignent jamais la destination parce quelles 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 A. Branzan-Albu & D. Laurendeau GIF 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 à dautres moments.

24 A. Branzan-Albu & D. Laurendeau GIF 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 derreur. protocole acknowledge Utilisation dun protocole basé sur un « accusé de réception » (acknowledge): si une source ne reçoit pas un accusé de réception dune destination après un certain laps de temps, elle retransmet les données en faisant lhypothèse quelles ont été perdues.

25 A. Branzan-Albu & D. Laurendeau GIF 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 A. Branzan-Albu & D. Laurendeau GIF 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 A. Branzan-Albu & D. Laurendeau GIF 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 Larchitecture des sockets BSD

29 A. Branzan-Albu & D. Laurendeau GIF Les sockets BSD sockets BSD application Larchitecture 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: Larchitecture des sockets BSD repose sur deux éléments principaux: sockets Les sockets ports Les ports

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

31 A. Branzan-Albu & D. Laurendeau GIF Les sockets BSD (3) Schéma type dune communication par sockets: Lhôte source transmet un paquet dinformation sur le socket en incluant 1. Le type de protocole 2. Ladresse de lordinateur hôte (réception) 3. Le numéro de port de lapplication (réception) 4. Ladresse de lordinateur source (transmission) 5. Le port de lapplication denvoi

32 A. Branzan-Albu & D. Laurendeau GIF 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, lapplication voit une abstraction unique

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

34 A. Branzan-Albu & D. Laurendeau GIF Les sockets BSD (5) 3. Numéro didentification de lapplication (ID), ou port: ce numéro identifie le port approprié sur lhô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 dinformation, la source sassure que la destination peut fournir linformation à la bonne application

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

36 A. Branzan-Albu & D. Laurendeau GIF Les ports (1) Lutilisation des ports est lun des fondements de la communication par sockets Chaque application choisit un numéro de port et, en diffusant ce numéro avec ladresse hôte, sassure que dautres applications peuvent sy connecter et y transmettre des informations Il existe ports. Les systèmes dexploitation peuvent donc supporter plusieurs applications simultanément

37 A. Branzan-Albu & D. Laurendeau GIF Les ports (2) Deux applications qui communiquent entre elles ne sont pas tenues dutiliser 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 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 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 dexploitation Les numéros de port 1024 à sont enregistrés pour être utilisés par des protocoles bien connus

40 A. Branzan-Albu & D. Laurendeau GIF 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 Lassignation des numéros de port est sous le contrôle de IANA (Internet Assigned Numbers Authority)

41 A. Branzan-Albu & D. Laurendeau GIF Les ports (6) Conséquences sur le design dapplications de VR distribuée: Lapplication de VR doit utiliser un numéro de port non enregistré Lusage recommande dutiliser un numéro de port entre et Si une application devient populaire, il est préférable de demander un numéro enregistré à lIANA

42 42 Le protocole IP (Internet Protocol) Notions de base

43 A. Branzan-Albu & D. Laurendeau GIF 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 dun point à un autre

44 A. Branzan-Albu & D. Laurendeau GIF 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 Len-tête de IP contient aussi un champ TTL (Time- To-Live) qui spécifie le nombre maximum de fois quun 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 A. Branzan-Albu & D. Laurendeau GIF 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, doù lappellation fréquemment rencontrée de TCP/IP

47 A. Branzan-Albu & D. Laurendeau GIF Le protocole TCP (2) TCP/IP donne limpression à une application quelle entretient une communication point-à-point avec une autre application

48 A. Branzan-Albu & D. Laurendeau GIF Le protocole TCP (3) Principales caractéristiques de TCP/IP: Connexion point-à-point bi-directionnelle Utilisation de messages daccusé 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 lhôte de réception La connexion sassure que le flot de transmission ne dépasse pas la capacité du réseau ni la puissance de calcul de lunité de réception

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

50 A. Branzan-Albu & D. Laurendeau GIF Le protocole UDP (2) Principales caractéristiques de UDP: Contrairement à TCP, UDP nassure pas une connexion entre les participants dune communication (aucune information sur létat de la communication nest 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 sils sont fragmentés, il faut sassurer que leur contenu ne sera pas perdu)

51 A. Branzan-Albu & D. Laurendeau GIF 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 quune communication « stream » TCP Il ny a aucune limitation sur le nombre de communication UDP quun OS peut traiter UDP est très bien adapté aux applications réseau à grande échelle

52 A. Branzan-Albu & D. Laurendeau GIF Le protocole UDP (4) UDP ou TCP? (2) Par ailleurs: UDP demande à chaque hôte de traiter tous les paquets même sils 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 datteindre certains hôtes sensibles.

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

54 A. Branzan-Albu & D. Laurendeau GIF Broadcasting ou multicasting? (2) Avec UDP/IP, les paquets ne sont transmis quaux 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 na pas à sidentifier, il na quà intercepter les paquets sur un port désigné pour lapplication ou à transmettre lui-même de linformation

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

56 A. Branzan-Albu & D. Laurendeau GIF Broadcasting ou multicasting? (4) Pour « broadcaster », un hôte na qua 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 , lapplication na quà adresser le message de broadcast à ladresse

57 A. Branzan-Albu & D. Laurendeau GIF 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 A. Branzan-Albu & D. Laurendeau GIF Broadcasting ou multicasting? (6) Le multicasting utilise une stratégie de distribution « receiver-controlled » Cette stratégie sinspire de celle dun 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 A. Branzan-Albu & D. Laurendeau GIF Broadcasting ou multicasting? (7) Les adresses à sont désignées comme étant des adresses « multicast ». En général les EV utilisent des adresses dans les intervalles suivants: 226.*.*.* à 231.*.*.* 233.*.*.* à 238.*.*.*

60 A. Branzan-Albu & D. Laurendeau GIF Broadcasting ou multicasting? (7) Un transmetteur envoie un paquet à ladresse multicast réservée à lapplication Les récepteurs préalablement enregistrés reçoivent ces paquets des distributeurs

61 A. Branzan-Albu & D. Laurendeau GIF Broadcasting ou multicasting? (8) La stratégie du multicasting est à comparer à celle du broadcasting qui sinspire 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 A. Branzan-Albu & D. Laurendeau GIF Broadcasting ou multicasting? (9) Si une application nécessite une adresse IP multicast permanente, il faut en faire la demande à lIANA Si une application à plus petite échelle ne requiert pas une adresse IP multicast permanente, elle peut en choisir une au hasard, mais en écoutant dabord le Session Announcement Protocol (SAP) pour savoir quelles adresses IP multicast sont présentement utilisées

63 A. Branzan-Albu & D. Laurendeau GIF 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, lapplication distribuée doit annoncer le choix de cette adresse

64 A. Branzan-Albu & D. Laurendeau GIF Broadcasting ou multicasting? (11) Conclusion: Le multicasting émerge graduellement comme lapproche recommandée pour la construction dEV 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 A. Branzan-Albu & D. Laurendeau GIF Quelques définitions Connexion logique: illustre le parcours dun message sur le chemin « logiciel » Connexion physique: illustre les liens physiques entre les participants

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

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

69 A. Branzan-Albu & D. Laurendeau GIF 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 A. Branzan-Albu & D. Laurendeau GIF Architecture peer-to-peer Architecture logique

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

72 A. Branzan-Albu & D. Laurendeau GIF 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 A. Branzan-Albu & D. Laurendeau GIF Introduction Lobjectif principal dun EV distribué est de donner aux utilisateurs lillusion quils partagent le même environnement Cet objectif peut être atteint si létat dynamique des entités présentes dans lenvironnement peut être partagé par tous les usagers

75 A. Branzan-Albu & D. Laurendeau GIF 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 sintéresse aux approches qui peuvent être adoptées pour le partage de létat dynamique des entités dans un EV distribué

76 A. Branzan-Albu & D. Laurendeau GIF Etat dynamique partagé Quest-ce que létat dune 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 dune simulation

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

78 A. Branzan-Albu & D. Laurendeau GIF 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 dune 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 A. Branzan-Albu & D. Laurendeau GIF Démonstration du compromis

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

81 A. Branzan-Albu & D. Laurendeau GIF 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 A. Branzan-Albu & D. Laurendeau GIF Dépôts centraux de données 2 3 n

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

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

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

86 A. Branzan-Albu & D. Laurendeau GIF 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 larrière-scène) Cette approche peut simplanter via un mécanisme « dabonnement » à létat dune entité

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

88 A. Branzan-Albu & D. Laurendeau GIF Mise-à-jour fréquente (1) Avec cette approche les entités sont la propriété dun 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é » à laveuglette (i.e. sans acknowledgement) aux autres hôtes

89 A. Branzan-Albu & D. Laurendeau GIF Mise-à-jour fréquente (2) Les autres hôtes maintiennent une cache où résident une description de létat de chaque entité de lEV Lorsquun update est reçu, lentité concernée voit son état rafraîchi dans la cache.

90 A. Branzan-Albu & D. Laurendeau GIF 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 dune entité à jour Deux politiques peuvent être adoptées: Utilisation dun lock manager pour attribuer la propriété avec un proxy updater Utilisation dun transfert de propriété (encore via un lock manager)

91 A. Branzan-Albu & D. Laurendeau GIF Mise-à-jour fréquente (4) (proxy)

92 A. Branzan-Albu & D. Laurendeau GIF Mise-à-jour fréquente (5) (proxy)

93 A. Branzan-Albu & D. Laurendeau GIF Mise-à-jour fréquente (6) (proxy)

94 A. Branzan-Albu & D. Laurendeau GIF Mise-à-jour fréquente (7) (transfert)

95 A. Branzan-Albu & D. Laurendeau GIF Mise-à-jour fréquente (8) (transfert)

96 A. Branzan-Albu & D. Laurendeau GIF Mise-à-jour fréquente (9) (transfert)

97 A. Branzan-Albu & D. Laurendeau GIF Mise-à-jour fréquente (10) Avantages de lapproche 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 lEV nest pas exigée, cela permet dinclure plus dentités dfans lEV

98 A. Branzan-Albu & D. Laurendeau GIF Mise-à-jour fréquente (11) Désavantages de lapproche 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 nest jamais à lendoit où il est sensé être selon laffichage graphique… 3. Le jitter cause aussi un problème de réalisme car, par exemple, la position dun objet peut être mise à jour de manière irrégulière

99 A. Branzan-Albu & D. Laurendeau GIF Prédiction (1) Lapproche 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 dun update Entre les mises-à-jour, létat de lentité 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 A. Branzan-Albu & D. Laurendeau GIF 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 A. Branzan-Albu & D. Laurendeau GIF Prédiction (3) Définition de technique de prédiction: Modèle physique ou non de lentité 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 A. Branzan-Albu & D. Laurendeau GIF Prédiction (4) Techniques de prédiction utilisées 1. Polynômes (dordre variable) Prédiction linéaire Prédiction avec des polynômes dordre 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 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 A. Branzan-Albu & D. Laurendeau GIF Prédiction (6) Convergence par snapping

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

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

107 A. Branzan-Albu & D. Laurendeau GIF Prédiction (9) Avantages de lapproche 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 nest pas générique

108 A. Branzan-Albu & D. Laurendeau GIF 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 nest assez générale pour offrir une solution adéquate dans diverses applications différentes


Télécharger ppt "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ésentations similaires


Annonces Google