5.4.2 Performances par rapport aux autres implémentations

Ayant à notre disposition l'implémentation HTTP de Microsoft et celle de Real Networks, nous étudions le comportement de notre implémentation par rapport à celles-ci. Les points que nous avons considérés importants et que nous pouvons mesurer sont :

• la latence avant le début de la visualisation d'un objet ; selon la méthode de compression, les lecteurs multimédias ont besoin de plusieurs informations pour décoder l'objet; ces informations sont situées à des endroits différents dans l'objet; récupérer ces informations pose un vrai problème pour une implémentation HTTP

• la latence moyenne pour une commande seek

La Figure 60 présente les temps de latence avant le début de la visualisation d'un objet multimédia pour les implémentations étudiées. Nous observons que notre stratégie de transfert par blocs offre des meilleures performances que les autres implémentations HTTP, que nous pouvons qualifier de "standard". Les modules de communication de WMP et RV sont optimisés pour le transport des données bas-débit sur Internet, et moins adaptés pour une communication haut-débit sur Intranet. A la différence de ces derniers, notre implémentation est optimisée pour une communication Intranet à haut-débit.

La commande seek peut avoir des latences très importantes pour les implémentations classiques de HTTP dans WMP et RV. En fonction de la taille de l'objet et de la position du seek, la latence peut arriver à des valeurs d'ordre de minutes ou même plus. Dans la Figure 61 nous présentons les temps moyens de latence pour un seek avec l'implémentation "transfert par blocs". Les sauts sont réalisés d'une manière quasi instantanée, condition importante pour un lecteur VoD. La différence de performance entre les modules pour WMP et RV est déterminée par les performances meilleures de WMP sur le système d'exploitation Windows.