Projet : ADP - adp

<body bgcolor="#FFFFFF" text="#000000" link="#9944EE" vlink= "#0000FF" alink="#00FF00"> <h2><a name="SECTION00035000000000000000" id= "SECTION00035000000000000000">Aide à la conception des applications multimédias</a></h2>  <a name="ADP_fondements_module-3-ACAM" id= "ADP_fondements_module-3-ACAM"></a> <p><strong>Mots clés :</strong> <i>application multimedia, architecture qualité de services, temps réel, allocation de ressources .</i></p> <h3>Résumé :</h3> <div class="ABSTRACT"> <i>Un nombre croissant d'applications reposent sur l'utilisation du multimedia :au sein d'une même présentation peuvent être utilisées à la fois des images animées, du son, du texte, etc. Ces applications se caractérisent par leur caractère distribué, par leur contraintes temporelles, et par la grande quantité de ressources requises. Pour tenter d'assouplir cette dernière caractéristique, un nombre croissant d'applications multimedia autorisent différents niveaux de qualité pour un même service, permettant ainsi d'adapter la qualité en fonction des ressources disponibles.</i> </div> <p>La généralisation des applications multimedia conduit inéluctablement à modifier l'infrastructure qui répartit les ressources entre les applications. Jusqu'à l'émergence du multimedia, les exigences de qualité de service des applications effectuant des transferts d'information se limitaient le plus souvent à vérifier l'intégrité des données échangées, afin d'éviter, par exemple, la corruption des fichiers transférés. Dans ce contexte, les ressources ne sont en général pas réservées, ce qui rend imprévisible la durée d'un traitement. Ce modèle, parfois qualifié de « paresseux (<span class="textit">best effort</span>) », est acceptable pour des applications où le traitement effectivement effectué est prépondérant sur les délais. <span class="textsl">A contrario</span>, le multimedia se caractérise, outre l'exigence - devenue « seulement » statistique - d'intégrité des données, par le respect de garanties temporelles, ce qui nécessite une certaine disponibilité du processeur, de la bande passante, de la mémoire, etc. [<a href= "bibliographie_Toc.html#BS97" target= "contents">BS97</a>].</p> <p>Le premier problème à résoudre est de vérifier la <span class="textit">cohérence des formats des données</span> échangées, afin de savoir si les différents équipements utilisés sont compatibles. Comme les flux multimedia sont maintenant bien standardisés, il n'est pas nécessaire de connaître le détail des protocoles utilisés. On peut considérer que ces flux sont typés pour effectuer la vérification de cohérence des formats des données échangées.</p> <p>Le second problème est posé par le respect des <span class="textit">contraintes temporelles</span>. Il s'agit de savoir si les délais et les fréquences d'arrivée des données sont compatibles avec les attentes des utilisateurs. Les contraintes temporelles sont de trois types. Les contraintes de synchronisation intra-flux expriment la régularité du flux en précisant le délai d'arrivée entre deux trames d'information. Les synchronisations inter-flux précisent les délais qui peuvent séparer l'arrivée des trames sur plusieurs flux liés. Enfin, le délai de bout-en-bout concerne le délai qui s'écoule entre le passsage d'une trame en un point de l'application et son arrivée en un autre point. Afin de vérifier le respect de ces contraintes, il est nécessaire de pouvoir connaître les performances des éléments employés, et de pouvoir en déduire si leur composition respecte les contraintes temporelles qui sont exprimées sur l'application.</p> <p>Le comportement temporel des éléments constituant l'application ne peut être garanti que si une certaine quantité de ressources est disponible. En effet, il est possible de trouver au sein de la plate-forme d'exécution plusieurs applications multimedia qui s'exécutent en concurrence. Dans ce cas, les ressources du calculateur et du réseau ont à être partagées par toutes les applications.</p> <p>Afin de permettre aux applications multimedia, très exigeantes en ressources, de s'exécuter avec le plus grand éventail possible de disponibilités en ressources, on a donné la faculté aux applications multimedia de fonctionner selon des modes plus ou moins dégradés. Dans un premier temps on a pu se satisfaire de solutions <span class="textit">ad hoc</span>, dans lesquelles les applications multimedia intégraient en leur sein des mécanismes d'adaptation de leur comportement en fonction des ressources disponibles. Mais ces solutions ont pour inconvénient d'être difficilement réutilisables et elles ne permettent pas une gestion coordonnée des ressources lorsque plusieurs applications s'exécutent.</p> <p>Des solutions middleware - appelées <span class= "textit">architectures qualité de service</span> - ont été proposées afin de décharger les applications de la gestion de l'adaptation. Pour profiter de leurs services, les applications doivent se conformer à un style d'architecture logicielle. Ce style spécifie entre autre les modalités d'interactions, l'interface des applications et le type des données pouvant être échangées.</p> <p>Le rÔle des architectures qualité de service (que nous abrégeons dorénavant par AQ<small>D</small>S) est d'effectuer la réservation et la renégociation des ressources de « bout-en-bout »[<a href= "bibliographie_Toc.html#ACH95" target="contents">ACH95</a>]. Ces mécanismes sont suffisants pour des applications où le serveur est lié au client directement par un réseau, comme c'est le cas souvent pour les applications de vidéo à la demande ; mais ces AQ<small>D</small>S ne permettent pas d'appréhender correctement les liaisons de bout-en-bout d'une application qui mettent en jeu plusieurs liens de machine à machine.</p> <p>Quant aux architectures qualité de service qui ne font pas d'hypothèse sur les éléments qui sont placés entre les extrémités, la complexité de leur représentation rend douteuse l'utilité à grande échelle des algorithmes proposés.</p> <p>Ces architectures qualité de service définissent une infrastructure de connexion, mais ne permettent de savoir qu'à l'exécution si une application multimedia peut s'exécuter ou non. Aussi nous sommes nous intéressés à la caractérisation de ces architectures afin de permettre de déterminer <span class="textit">a priori</span> si la combinaison d'une application multimedia et d'une AQ<small>D</small>S est, d'une part, compatible pour le format des données échangées et, d'autre part, que cette combinaison permet bien le respect des contraintes temporelles de l'application multimedia.</p> </body>