5.1.3 Les défauts de la stratégie actuelle

Comme nous l'avons précisé dans l'introduction du chapitre, cette stratégie de transfert à un certain nombre de défauts.

Premièrement, le temps d'interaction pour la réalisation d'un seek est important. Une fois que le transfert est commencé, le lecteur client ne peut pas faire une opération SEEK sans attendre qu'une quantité de données inutiles soit transférée (Figure 50). Les données situées entre la position courante à la réception du SEEK et la nouvelle position désirée seront transférées même si elles ne sont pas nécessaires pour la visualisation (dans le cas où les données ne seraient déjà transférées).

Nous sommes tentés de nous demander pourquoi ne pas fermer la connexion HTTP et la re-ouvrir après chaque seek. Dans ce cas les données inutiles ne sont pas transférées. Mais on tombe sur le problème de "slow start" du HTTP Chapitre 2), problème qui générera des latences importantes pour chaque opération seek.

Un autre effet de cette utilisation du HTTP réside dans l'utilisation inefficace de la bande passante. L'exemple de la Figure 51 montre la différence entre le débit avec les données arrivant au client (le serveur les envoie le plus vite possible) et le débit réel du flux. On voit que le flux est transféré assez vite par rapport à son taux réel d'encodage (le débit réel du flux). Si la visualisation s'arrête après un certain temps, une bonne quantité de données sera transférée inutilement.