Lecteur multimédia

Le lecteur multimédia communique avec un ou plusieurs serveurs Web et avec le poste d'administration.

Il utilise la stratégie HTTP présentée dans cette thèse (Chapitre 5) à travers un filtre pour WMP ou RV; si le filtre est indisponible il peut travailler avec une autre stratégie HTTP, mais le système n'offrira pas dans ce cas des performances optimales (Chapitre 5).

Le filtre HTTP est lancé avec une adresse URL comme:

http://RServer/path/object.mpg

RServer représente l'adresse de la machine hébergeant le composant d'équilibrage de charge (ResourceSpy). Le filtre se connecte à ce logiciel qui lui fournit les noms de serveurs Web contenant l'objet object.mpg et leur degré d'occupation. Le filtre utilisera le serveur le moins occupé (server1, Figure 85) pour retrouver l'objet object.mpg. Si le serveur server1 n’est pas en mesure de répondre à la demande, le deuxième serveur le moins occupé (server2) sera utilisé pour le transfert par blocs de object.mpg.

Figure 85 Utilisation de la stratégie HTTP "transfert par blocs" avec plusieurs serveurs Web. Si un serveur est indisponible, le client utilise un autre serveur contenant le même objet.

Nous avons effectué des tests montrant que le passage d'un serveur Web à un autre serveur contenant le même objet object.mpg n'influence pas la qualité de la perception au niveau utilisateur (le transfert entre les deux serveurs se fait en moins d'une seconde, 3 secondes de contenu étant disponibles dans la mémoire tampon).

Le composant d'équilibrage de charge (ResourceSpy) fournit aussi au filtre l'adresse de MA, où le filtre enverra les informations nécessaires pour la facturation et la surveillance du système.

Figure 86 Composants communiquant avec le lecteur client

Dans le cas où ResourceSpy n'est pas joignable, le filtre considérera RServer comme le serveur Web où se trouve object.mpg, conformément à la sémantique http. Cette adresse reste valide si ResourceSpy est hébergé sur un serveur de contenu.