Une des parties les plus importantes d'une plate-forme de développement d'en-vironnements virtuels distribués est celle qui a la charge de distribuer l'environne-ment virtuel sur les diérents sites. Cette partie doit garantir la communication entre les sites en gardant toujours un certain niveau de abilité. Plusieurs facteurs peuvent aecter la communication entre les sites, comme la bande passante, la latence et la abilité de la transmission.
2.3.1 Bande passante
La bande passante est la capacité maximale de débit sur une liaison donnée. La bande passante joue un rôle majeur dans la communication inter-sites car c'est elle qui détermine la taille et la richesse d'un environnement virtuel distribué. Plus le nombre des participants s'accroit, plus on a besoin d'une bande passante importante. Ceci est lié à diérentes raisons. Tout d'abord, chaque nouvel uti-lisateur doit recevoir l'état initial de l'environnement ainsi que ses mises-à-jour. Il doit pouvoir aussi introduire ses modi cations de l'environnement partagé à distribuer chez les autres participants.
En fait, les systèmes de développement d'environnements virtuels distribués nécessitent un débit important pour pouvoir supporter les utilisateurs multiples et les échanges vidéos et audios. Dans les réseaux LAN ce problème est résolu grâce au très haut débit oert par les nouvelles technologies, mais par contre le nombre de participants est limité. Quant aux réseaux WAN le débit est plus limité que celui oert par les LAN mais ils permettent un nombre d'utilisateurs beaucoup plus important.
2.3.2 Latence
La latence est un facteur qui aecte directement la communication dans les environnements virtuels distribués. La latence peut dégrader la communication en retardant la réception des messages émis sur le réseau (Fig. 2.3). Si un envi-ronnement distribué doit imiter le monde réel, il doit agir en temps réel dans les limites de la perception humaine. En d'autres termes une plate-forme de dévelop-pement d'environnements virtuels distribués doit délivrer des paquets avec une
4Frequently Asked Questions on the Multicast Backbone (Casner, S.) : ven-rera.isi.edu:/mbone/faq.txt
Communication 37 latence minimale (inférieure à 100ms) et doit générer une structure graphique 3D à une fréquence allant de 30 à 60 Hz pour garantir l'illusion de la réalité [Wlo95].
Tem ps Tem ps Tem ps Tem ps
Message
Communication sans délai Communication avec délai
Fig. 2.3 Communication sans et avec latence
La variation de la latence en fonction du temps est aussi un facteur qui per-turbe le fonctionnement des application interactives. Sawler a noté dans [Saw91] qu'une latence variable au cours du temps est aussi importante que la latence elle même, particulièrement dans les tâches qui exigent un niveau de synchronisation élevé. Le problème de latence est devenu un dé pour les systèmes qui utilisent les réseaux WAN à cause de l'aectation de la transmission par plusieurs types de retard : des longs chemins, des switchs, des routeurs, traitement de paquets, les d'attentes... D'après [Tan90], les plus importants de ces retards sont :
le temps de traitement à chaque n÷ud : le temps de traitement est le temps requis pour l'examen de l'en-tête d'un paquet et la détermination de son destinataire. Le temps de traitement peut être déterminé par le temps requis pour la véri cation des erreurs dans le paquet lors de son transfert.
le temps d'attente : le temps d'attente correspond au temps nécessaire pour faire parvenir le paquet jusqu'à la liaison qui l'acheminera vers le prochain routeur. Le temps d'attente d'un paquet dépend du nombre de paquets qui le précèdent dans le routeur.
le temps de transmission : le temps de transmission correspond au temps requis pour transmettre tous les bits du paquet sur la liaison.
le temps de propagation : le temps de propagation est le temps nécessaire au trajet entre l'origine de la liaison et le routeur destination. Un bit se propage à la vitesse de propagation d'une liaison, qui est déterminée par son support physique.
38 Réseaux et systèmes distribués En plus des diérents retards sur le réseau, un paquet peut aussi être perdu. En eet, les les d'attente sont d'une capacité limitée. Un paquet peut tout à fait rencontrer une le d'attente complète et fermée à son arrivée dans le routeur. En l'absence d'espace libre pour stocker un paquet, le routeur l'abandonne et le paquet est dit perdu.
La latence peut être minimisée en utilisant des liens spéciaux qui utilisent des protocoles tels que Reservation Protocol [Dee93], des améliorations dans la technologie des routeurs, l'utilisation des interfaces rapides. Cependant elle ne peut pas être éliminée complètement.
Dans le contexte d'une plate-forme de développement d'environnements vir-tuels, la continuité d'une scène et le contrôle de sa uidité ne sont plus possibles si la latence devient importante. Par conséquent, les interactions deviennent de plus en plus di ciles à réaliser. Plus de détails sur ce problème sont présentés dans le chapitre 4.
2.3.3 Fiabilité
Un système est dit able s'il peut s'assurer que les données envoyées sont reçues correctement. Cela peut parfois nécessiter un réenvoi des données.
Pour garantir la abilité, l'architecture des réseaux dans les couches basses utilise des acquittements. Cette technique implique malheureusement un grand délai dans le cas d'un réseau WAN ou d'un système distribué à grande échelle. De plus, quelques protocoles de transport comme TCP par exemple utilisent des mécanismes de contrôle d'encombrement qui ne conviennent pas pour le tra c en temps réel, parce que ces techniques diminuent le taux de transfert des paquets dans le cas de détection d'encombrement. Le protocole de Multicast able n'est pas très utilisable pour les grands groupes qui utilisent le même environnement virtuel à cause du nombre des acquittements et des retransmissions nécessaires a n de garantir que tous les utilisateurs aient reçu les mêmes données.
Les problèmes posés suite à la abilité ne veulent pas dire que les chercheurs n'essaient pas de développer un service de Multicast able qui puisse le mieux ré-pondre aux exigences des systèmes de développement d'environnements virtuels. Par exemple, la communication dans DIVE (Distributed Interactive Virtual En-vironment) [CH93], développé à l'institut suédois de l'informatique, est assurée par ISIS, un système développé par Ken Birman qui utilise un Multicast able. Brian Whetten et Simon Kaplan ont développé RMP (Reliable Multicast Proto-col) qui est aussi un protocole de Multicast able basé sur l'utilisation des acquit-tements négatifs. L'inconvénient de cette méthode est l'explosion exponentielle du nombre d'acquittements négatifs qui provoque l'encombrement du réseau. Cela arrive lorsque tous les récepteurs d'un groupe envoient simultanément un acquit-tement négatif qui, ajouté à l'encombrement partiel du réseau, a pour conséquence
Distributionde données 39 la perte de plus de paquets. Ceci entraine encore plus d'acquittements négatifs sont envoyés, ce qui mène à un encombrement total du réseau.
On peut conclure que le choix d'un seul protocole Multicast ( able ou non) ne satisfait pas tous les besoins d'un environnement virtuel distribué. Un tel environnement nécessite l'utilisation des deux protocoles, l'un able et l'autre non able, à utiliser selon les besoins pour avoir un compromis acceptable.