5.1 Introduction

Le protocole HTTP est conçu pour une communication continue monodirectionelle. De ce fait, pour l'implémentation de fonctionnalités telles que le déplacement de la position de lecture sur un objet multimédia ("seek"), le client doit attendre que les données entre la position courante et la position du seek soient transférées. Ceci impose une attente à l'utilisateur et un transfert important de données inutiles.

Un autre problème dû à l'utilisation de ce protocole réside dans l'utilisation inefficace de la bande passante. Le serveur classique, en réponse à une requête sur un objet, essaie d'envoyer l'objet le plus vite possible, en générant une utilisation inefficace de la bande passante, qu'il s'agisse d'un clip audio de quelques secondes ou d'un film de plusieurs heures. RealNetworks a publié des statistiques selon lesquelles la longueur moyenne par écoute est d'approximativement 4 minutes, mais souvent le matériel source a une heure ou plus [rn-http]. Il y a donc un besoin fondamental de contrôler le taux de transfert d'un objet multimédia.

Plusieurs lecteurs multimédias utilisent le protocole HTTP ([ms-wmp], [rn-rp], [vivo], [xing], [mpegtv]), souvent comme alternative a d'autres protocoles multimédias spécialisés (d'habitudes pour passer les pare-feu), mais leurs stratégies se heurtent aux problèmes présentés ci-dessus.

Pour résoudre ces problèmes, nous décrivons une nouvelle méthode d'utilisation du protocole HTTP. Cette méthode correspond à une stratégie de travail type "pull" depuis le client (voir Chapitre 3) et permet l'utilisation efficiente de l'opération "seek" et un certain contrôle de la bande passante. La quantité de données inutiles qui traversent le réseau sera ainsi limitée à des quantités négligeables. Cette méthode ne demande aucune modification du serveur Web : seule la stratégie des requêtes HTTP coté client est modifiée, en gardant le protocole inchangé.