5.3.2.3 Considérations pour choisir la taille d'un bloc

Le problème que nous nous posons est de déterminer les tailles de blocs acceptables pour cette stratégie de transfert. On sait que la taille d'un bloc doit être assez grande pour ne pas surcharger le réseau et le serveur HTTP (section 5.2.1), mais pas trop grande pour garder une bonne latence pour les commandes VCR étendues, notamment seek (section précédente).

Si on connaît la surcharge maximale que l'on accepte pour le réseau, à partir de ( 20 ) on obtient :

où surcharge réseau représente la surcharge du réseau par rapport à l'autre stratégie de transfert HTTP.

Pour exprimer la taille du bloc on arrive à :

On en déduit, en utilisant ( 22 ) et ( 2 ) :

Dans le cas particulier où l'en-tête HTTP à une taille de taille H = 256 octets, la latence maximale tolérable sur un seek latence_moyenne seek = 0.5 seconds, le nombre maximal de clients clients no = 50, le réseau est un réseau Fast-Ethernet (bw = 100 Mbps) et la surcharge maximale acceptable du réseau de 2,5% (surcharge réseau = 0.025), la taille d'un bloc devra se situer dans les limites [20 Koctets, 122 Koctets].

La relation ( 3 ) nous oblige également à accepter des valeurs raisonnables pour surcharge réseau et clients no, des valeurs respectant la relation :

Si cette relation n'est pas satisfaite, la stratégie de transfert par blocs ne pourra pas fournir une solution efficace pour le système étudié.

Dans les tests que nous faisons dans cette thèse nous travaillons avec de blocs de taille 32 KB ou 64 KB. Ces valeurs vérifient les conditions ( 3 ) pour toutes les configurations que nous avons utilisées. D'autres valeurs peuvent être utilisées, en fonction des caractéristiques particulières d'un système VoD (des objets à débit très élevé ou très bas, par exemple) mais elles doivent vérifier ( 3 ).