Sc´ enario d’application

Ce service de transcodage de vid´eo d´emontre l’int´erˆet de laisser les services actifs choi-sir le bon moment pour intercepter des paquets : ´economiser les ressources de la passerelle quand le traitement des paquets n’est pas n´ecessaire. Un utilisateur mobile re¸coit un flot de vid´eo MPEG ´emis par un serveur de vid´eo. Le fournisseur de r´eseau a d´eploy´e sur une passerelle active pr`es du lien sans fil un service de transcodage. Au d´ebut, seul un moni-teur de RTCP est activ´e sur la passerelle pour examiner la qualit´e de transmission. D`es le d´ebut le moniteur de RTCP injecte un filtre de paquets concernant seulement le flot RTCP pour intercepter les paquets RTCP contenant les informations de statistique envoy´ees par le terminal de l’utilisateur. Si la qualit´e de transmission est bonne, le flot RTP traverse la passerelle active sans intervention de celle-ci. Le service de transcodage est activ´e mais dors (bloqu´e), aucun filtre de paquet concernant le flot RTP n’est inject´e dans le noyau. Par cons´equent, les ressources de la passerelle sont r´eserv´ees `a l’acheminement des paquets, et aucune charge du CPU n’est g´en´er´ee pour passer des paquets de RTP au service de trans-codage. Quand le moniteur de RTCP d´etecte une d´egradation de la qualit´e de transmission (quand le client mobile est ´eloign´e du point d’acc`es), il r´eveille le service de transcodage. Le service de transcodage injecte un filtre dans le noyau pour intercepter le flot de RTP, et commence la tˆache de transcodage. La d´efinition de la vid´eo peut alors ˆetre r´eduite de moiti´e, ou encore le flot est transcod´e dans le format H263 afin de r´eduire le trafic envoy´e au client. Grˆace `a ce service, le client peut encore voir la vid´eo. L’impl´ementation de ce service est d´ecrit plus en d´etail en section 6.2.1.

3.4 Conclusion

Dans ce chapitre nous avons pr´esent´e l’architecture d’une passerelle active g´en´erique. Si on la compare avec d’autres architectures comme Router Plugins [47], PromethOS [56] ou ALAN [60] etc, l’architecture de ProAN pr´esente les nouveaux concepts suivants :

– Elle est g´en´erique car elle peut supporter plusieurs environnements d’ex´ecution diff´erents. – Les filtres de paquets sous ProAN peuvent impliquer n’importe quelle portion de

donn´ees d’un paquet IP - du niveau r´eseau `a celui d’application.

– Les services actifs sous ProAN peuvent aussi traiter des PDUs de n’importe quel niveau protocole : r´eseau, transport ou application

– Les services actifs sous ProAN d´ecident eux-mˆeme du moment d’installer et d´esinstaller des filtres de paquets. Dans d’autres architectures ces filtres sont inject´es d`es l’acti-vation du service et sont enlev´es au moment de la fin du service. Ceci demande au nœud actif de passer le flot de paquets demand´e au service, mˆeme dans le cas o`u aucun traitement n’est n´ecessaire.

– Dans d’autres architectures, la communication entre l’utilisateur et un service actif activ´e sur un nœud actif est directe. Dans ProAN cette communication se fait par l’interm´ediaire du module de contrˆole de la passerelle. C’est `a ce module de contrˆole

3.4. CONCLUSION 61 d’avertir, par des ´ev´enements, le service actif des commandes envoy´ees par l’utilisateur. Par cons´equent les services actifs n’ont plus besoin d’inclure le module d’authentifica-tion et de gesd’authentifica-tion d’utilisateurs dans le code.

Dans le chapitre suivant, nous pr´esenterons un environnement d’ex´ecution appel´e GateS-cript et une approche g´en´erique pour ´ecrire des services actifs sous ProAN.

Chapitre 4

Environnement d’ex´ecution de

GateScript

4.1 Motivation

Un service actif doit g´en´eralement traiter le contenu d’un flot des donn´ees et personnali-ser le comportement d’un protocole que l’on veut enrichir. Il analyse, traite et formatte des PDUs. En g´en´eral, ces fonctionnalit´es sont combin´ees dans un mˆeme code. Par cons´equent quand la structure de donn´ees ou de PDU est chang´ee, tout doit ˆetre recompil´e, recharg´e, et ces codes sont parfois complexes et difficiles `a maintenir et d´evelopper (beaucoup d’efforts pour tester, corriger des fautes et des erreurs). Notre approche propose de s´eparer la fonction d’analyse et de formattage de celle de traitement des donn´ees. Nous proposons ´egalement d’employer un langage de description pour d´ecrire la structure des PDUs et des donn´ees. Un compilateur est ensuite utilis´e pour produire l’analyseur et le g´en´erateur des PDUs au-tomatiquement `a partir du fichier de description. Ce langage de description facilite la tˆache de la programmation du service actif avec des flots de donn´ees. Chaque fois que la PDU change de structure (une option ou une entˆete est ajout´ee) il suffit de recompiler le fichier de description des PDUs.

De plus, nous fournissons un langage de script g´en´erique appel´eGateScript pour composer des services actifs, que ceux-ci traitent des paquets au niveau r´eseau, ou des PDUs au niveau application. Le langage GateScript supporte aussi les services proactifs en permettant de traiter les ´ev´enements et les variables de l’environnement.

Pour atteindre notre but de s´eparer la fonction d’analyse et de formattage de celle de traitement des donn´ees, nous pr´esentons dans la section suivante une architecture g´en´erique des services actifs pour l’environnement d’ex´ecution GateScript.