Lorsque l’on parle de “streaming” arrive toujours l’idée de “vidéos en ligne”. Cette analogie n’est pas fausse en soi, mais disons plutôt incomplète. Le streaming ne sert pas seulement à envoyer de la vidéo ou du son à la volée…

Les développeurs PHP, JSP, .net etc… tout comme moi ne sont pas habitués au principe de serveur de stream. D’abord pour une histoire de concept, mais aussi pour le coté “conception de l’application”. Notre type de travail est en général destiné à développer coté serveur des scripts ou programmes qui vont réagir à une demande. Le concept de streaming va un peu plus loin et demandera de concevoir l’application coté serveur et client en même temps.

C’est là la complexité du travail, mais aussi sa puissance. Alors avant d’aller trop loin dans les explications, allons y en douceur en reprenant concept par concept les méthodologies afin de mieux capter le principer de streaming.

Le serveur HTTP

Les acteurs

Dans les principes de service internet, nous identifions pratiquement toujours 2 acteurs. Parfois 3.

- le client
- parfois un proxy
- le serveur\

Le client est généralement (en ce qui concerne le net) un navigateur: Firefox, Safari, Internet Explorer…

Pour pratiquement 80% des cas, le serveur est Apache, sinon IIS.

Un proxy n’est qu’un intermédiaire qui va autoriser le client à appeler le serveur à travers lui. Il pourra garder en mémoire les pages récupérées depuis le serveur pour les retransmettre au client sans avoir à rappeler le serveur. C’est ce que l’on appelle un “proxy cache”. Généralement utilisé en entreprise, nous allons outrepasser ce sujet.

L’ordre des choses

La plupart du temps, vous naviguer sur des serveurs HTTP. C’est le protocole standard du web. Le simple fait de visiter un blog se découpe 3 phases:

 - le client (navigateur) appelle une page (http://www.metal3d.org/index.php/blog) - je vous passe les détails de résolution de nom de domaine etc...
 - le serveur Web intercepte la demande et retourne la page - je vous passe la génération de la page si elle est dynamique ou non...
 - le client interprète le code HTML pour vous donner l'aspect (mise en page, couleurs, polices..)
 

Ce mode est donc synchrone, rien ne se passe sans que le client n’effectue une demande et rien ne fonctionne en parallèle. On doit constamment attendre la réponse du serveur… et le serveur doit constamment attendre une demande cliente…

Problématique

=

mode synchrone

Le problème appairait dés lors que vous aimeriez prévenir le client d’une modification, d’un message, ou quoique ce soit alors que ce dernier ne fait pas de requête. Prenons un exemple:

Le client appelle la page http://www.example.com/ qui lui fait apparaitre ses e-mails. Quand la page est affichée, tout les processus sont terminés. Imaginons qu’un nouveau message soit adressé au client.

Étant donné que seul le client peut effectuer une requête, il faut qu’il rafraîchisse la page, c’est à dire renvoyer une requête, pour voir le nouveau message. Si jamais le client ne met pas à jour la page, il n’affichera jamais le nouveau message. Il est possible de faire en sorte que le client rafraîchisse automatiquement la page toutes les X secondes, demandant alors le traitement de toute la page à chaque fois.

mode asynchrone

Un début de réponse à la problématique est Ajax. Cette méthode permet de réduire le coût de bande passante en effectuant des appels plus légers et ne modifiant que des petites zones de la page de message. Le soucis c’est que nous allons encore une fois devoir définit le temps entre chaque appels Ajax à effectuer, puis traiter la réponse.

Biens que cette méthode soit simple et efficace, elle n’en est pas moins contraignante. Si le client est lent ou que le taux de connexion est très faible, le temps entre chaque appels serveur devra être considérable. Sauf que parfois, nous avons besoin d’avoir un temps très court entre chaque requête.

Par exemple, un petit chatroom serait peut agréable si il fallait attendre plusieurs secondes avant de voir la réponse d’un correspondant.

Ce n’est pas encore la meilleure solution, mais cela peut suffire dans bien des cas.

Le streaming

Le streaming n’est pas simplement conçut pour recevoir des vidéos ou du son. Bien que le streaming soit particulièrement adapté pour cela, les préconçus sont trompeurs et il faut remettre les choses à leur place.

Un stream est un flux continue permettant de faire transiter des informations entre deux points sans se soucier de leur sens. Ok, je vais un peu vite, je vais reprendre mon explication.

Un serveur de streaming attend une connexion cliente, sitôt qu’elle est effectuée le stream se met en place entre le client et le serveur. A l’inverse du service HTTP, le serveur de stream ne coupe pas la connexion entre les deux points après avoir répondu, cette fois ci il attend.

L’intérêt réside dans le fait que maintenant, ce n’est plus seulement le client qui effectue des requêtes mais il pourra aussi répondre à tout moment à un appel serveur. De ce fait, dans notre exemple de messagerie, si un message arrive sur le serveur, le serveur alerte immédiatement le client de son arrivé. Le client pourra alors interagir en conséquence, et si le message est lut, supprimé, déplacé… le client informe le serveur via le stream. Plus besoin de faire des requêtes toutes les X secondes…

Vous l’aurez donc compris, avec un stream ce n’est plus seulement le serveur qui écoute, mais aussi le client. De ce fait, vous allez pouvoir mettre en place un système d’écoute coté client qui va réagir à un appel serveur.

Client et Serveur de stream ?

Parmis les client stream, nous avons VLC qui sait recevoir un flux vidéo ou audio depuis le réseau, mais aussi plus largement le plugin Flash. En effet, Youtube, Deezer ou Dailymotion envoient leur flux vidéo dans un stream. L’intérêt pour eux et de pouvoir détecter le débit réseau entre le serveur et le client afin de ne démarrer la lecture qu’au moment où le client a assez de donnée en tampon.

Les chatroom flash sont aussi très prisés car le serveur de stream envoi les messages en temps réel (ou presque) et permet l’envoi et la réception de vidéo via une webcam.

Parmis les serveurs, il y en a deux qui sortent du lot. Le premier est FMS (Flash Media Server) de Adobe. Relativement onéreux, il est orienté pour les service à fort trafic. Reste Red5, solution opensource très efficace, développé en Java, qui fonctionne à merveille. Son principal //défaut// (ce n’en est pas forcément un) est qu’il n’est pas simple de créer son service si nous n’avons pas de connaissance solides en Java et en Programmation Orientée Objet.