|
|
||
|
OPNET Technologies OPNET is a registered |
Contributeurs : Julien Bourgeois, Sofiane Sellah, Srikanth B. Yoginath
Objectifs du modèle Dans la perspective d’étudier
le comportement des applications multimédia et de proposer de nouveaux mécanismes
et de nouvelles techniques dans le transfert du multimédia il s’est avéré que
le recours à la modélisation est un choix inévitable pour des raisons économiques
et techniques. Ainsi pour couronner les
efforts qui ont été fait dans le cadre de MoVie et tester
l’efficacité de solutions proposées afin améliorer les services et les
applications multimédia dans les réseaux sans-fil. L’objectif initial de cette
étude était de réaliser un modèle de dispositif de transcodage multimédia dont
le rôle est d’adapter les flux multimédia provenant d’un serveur ou plusieurs
serveurs. Mais en réalité les modèles de client et serveur qui existent dans l’outil
de modélisation que nous avons choisis sont implémenté au niveau frame, c'est-à-dire que l’unité d’échange entre le
client et les serveurs est le bloc d’image (frame).
Le découpage et le transport de ces blocs se fait au niveau du protocole de
transport tels que TCP ou UDP. Par contre, un
mixeur agit sur des formats de paquets définis dans la norme RTP (Real-time Transport Protocol).
Nous avons décidé de commencer par le développement d’un modèle client et d’un
modèle de serveur qui communiquent par l’utilisation
du protocole RTP. Au terme de cette première étape
nous disposerons de deux composants réseaux (nœuds) qui intègrent des fonctionnalités
de transfert de flux multimédia conforme aux normes RTP et RTCP (Real-time Transport Control Protocol).
Dans la deuxième étape de ce travail. On propose de passer d‘une architecture à
deux tiers (client – serveur) pour la transmission de flux multimédia à une
architecture à trois tiers. Ceci nécessite d’apporter des modifications sur les
deux modèles de client et de serveur développés précédemment, puis de
développer le composant mixeur. Concepts de modélisations
avec OPNET Modeler OPNET Modeler présente trois domaines
de modélisation organisés de manière hiérarchique : Le domaine réseau, le domaine
nœud et le domaine processus. 1.
Domaine réseau
(network domain) C’est le niveau le plus élevé
de la modélisation. Il s’agit à ce niveau d’exploiter des modèles qui sont déjà
existants dans la bibliothèque pour construire un modèle de réseau. On peut choisir
la topologie du réseau, le type de liens pour interconnecter les composants du réseau,
les dispositifs réseau (hubs, routeurs, stations de travail).
Chaque élément utilisé dans le modèle réseau est appelé nœud (node) dont
l’architecture interne est décrite dans un niveau plus bas appelé niveau nœud (node domain).
Figure 3. Exemple d’un modèle de réseau dans OPNET Modeler
2.
Domaine nœud (node domain) À ce niveau est décrite l’architecture interne
d’un nœud. En effet, un nœud dans OPNET Modeler est composé de trois types de
modules -
les processeurs qui
sont des entités entièrement programmables. -
les files
d’attentes servant pour le stockage et la manipulation des paquets. -
les émetteurs/récepteurs,
qui constituent l’interface de communication inter- nœuds (généralement entre un
dispositif réseau et un lien). Les modules d’un nœud utilisent deux
mécanismes de communication -
le flux de
paquets (packet streams)
pour s’échanger les paquets de données comme par exemple le passage de
paquets d’une couche à une autre dans la pile des protocoles. -
fil de
statistiques (statistic
wires) utilisé essentiellement pour communiquer
les statistiques entre les modules. (voir figure)
Figure 4. Exemple d’un nœud dans OPNET Modeler 3.
Domaine
processus (processus domain) C’est le niveau le plus
important dans OPNET Modeler. Avant de commencer Il est important de faire la
distinction entre un modèle de processus et un processus. En fait, la relation
entre les deux est comme la relation entre une classe et une instance de cette
classe. Dans les problèmes de modélisation on parle souvent de modèle de
processus, par contre dans la simulation parle de l’instance de processus. Dans OPNET Modeler, le comportement
d’un module est défini par un ou plusieurs processus. Ce paradigme est appelé process
group. Quand on lance la simulation, chaque module contient un seul
processus appelé processus racine (root process).
Ce processus peut, au fur et à mesure de l’avancement de la simulation, créer
d’autres processus qui sont appelés processus fils (child
processes). OPNET Modeler ne met aucune limite
sur le nombre de processus qui peuvent être créés dans un module. Les processus
crées par le root process
sont appelés processus dynamiques.
Ce paradigme offre plus de souplesse pour la modélisation de systèmes
multitâches Le principe d’invocation de
processus dans OPNET Modeler est similaire à l’appel de fonctions dans le
langage C. Un processus en cours d’exécution peut invoquer un autre et se
bloquer. Le processus invoqué commence l’exécution et peut à son tour invoquer
d’autres processus. Lorsqu’il se termine, il rend la main au processus
appelant. Les processus Modeler sont
conçus pour répondre aux interruptions provenant d’eux-mêmes (self
invocation), d’autres processus du processus group c’est-à-dire dans
le même module, ou à des processus appartenant à un autre module. Les
interruptions correspondent à des événements tels que l’arrivée d’un paquet,
l’expiration d’un timer, la libération d’une ressource ou le changement
d’une statistique dans un autre module (static
wire). Le traitement d’une interruption se
termine lorsque le processus invoqué se bloque. Les processus sont programmés
en Proto-C qui est langage conçu pour simplifier la
modélisation des protocoles et des algorithmes. Ce langage est la combinaison
d’un formalisme basé sur les diagrammes état/transition appelé aussi STD (state/transition
diagram) et d’une bibliothèque de kernel procédures. Il utilise les fonctionnalités du
langage C ou C++. OPNET Modeler intègre un
nouveau mécanisme de communication interprocessus appelé ICI (Interface Control
Information). ICI est constitué de structures de données configurables pouvant
être attachées avec les interruptions ou les flux de données. Lorsqu’une
application envoie un paquet à la couche session il l’accompagne d’une ICI qui
détermine l’identifiant unique de la session à laquelle ce paquet appartient. Les processus dans OPNET sont
dits interruption driven. Lorsqu’un processus
reçoit une interruption il agit en faisant la transition qu’il faut. Cette
transition peut conduire à un changement d’état ou à boucler sur le même état.
Deux types d’états existent dans Modeler, les états forcés (représentés
par une couleur rouge et les états non-forcés,
représentés par une couleur verte. La différence entre ces deux types d’état
est qu’un état forcé est bloquant, c’est-à-dire que le processus se bloque sur
cet état jusqu'à la réception d’une nouvelle interruption. A contrario, un état
non forcé est non bloquant. L’éditeur de processus de
Modeler intègre plusieurs fonctionnalités avancées qui facilitent le
développement : - Les variables d’état : ce sont des variables privés qui permettent de
maintenir des informations sur l’état du processus comme les compteurs, les
tables de routages ou les statistiques. Ces variables gardent leurs valeurs
tout au long de la vie du processus, contrairement aux variables temporaires
qui perdent leur contenu à chaque nouvelle invocation du processus. - Les exécutifs d’états : on peut
spécifier un ensemble d‘actions à exécuter à chaque entrée ou sortie de l’état.
Cet ensemble est appelé exécutif. Un exemple de ces actions peut être la
modification du contenu d’une variable, la mise à jour d’une statistique ou le
déclenchement d’un timer. - Les conditions de transition : c’est une expression booléenne qui détermine
quand une transition doit être traversé. - L’exécutif de transition : c’est un ensemble de code qui doit être
exécuté à chaque fois que la transition est traversée. Voir Figure 5
Figure 5. Exemple d’un modèle
de processus dans OPNET Modeler Modélisation d’une architecture
deux tiers pour la transmission de flux multimédia Introduction Comme toute application
distribuée, l’application de demande de vidéo/audio est divisée en deux
parties, une partie client et une partie serveur qui communiquent par un
protocole commun. Le cas le plus simple d’une application multimédia est la
demande d’audio/vidéo enregistrée sur un serveur distant. Nous allons nous
intéresser ici au cas où le client et le serveur se mettent en accord sur un
type de payload, et sont prêts à commencer
l’échange de données. On ne traitera pas la négociation du type de payload ni les fonctionnalités du protocole RTSP.
Figure12. Protocoles
intervenant dans une session multimédia Implémentation des modèles de processus client et
serveur Afin de modéliser le client
et le serveur RTP, nous sommes partis d’un projet de l’Illinois Institute of Technology, Chicago,
où Srikanth B. Yoginath a
développé un modèle de la couche RTP. Nous avons
ajouté à son modèle la possibilité de faire d’ouvrir plusieurs sessions et
également une gestion plus développée de RTCP. En général, les actions qui
doivent être entreprises par le client et le serveur se résument dans les
étapes suivantes : 1.
Phase
d’initialisation des applications, sur les deux parties 2.
Etablissement de
la session entre le client et le serveur. 3.
L’envoi des
données (multimédia) par le serveur au client, et l’envoi des apports SR 4.
La réception des
données par le client, mise ajours des statistiques, envoi des rapports. 5.
La clôture de la
session par le serveur lorsque il aura terminée le transfert. 1.
Phase
d’initialisation Les deux processus client et
serveur vont initialiser leurs variables d’états et les attributs qui vont être
utilisés pendant la session et enregistrer les statistiques à récupérer. Comme
les deux processus sont implémentés dans la couche supérieure, et que le bon
fonctionnement de ces deux processus dépend des processus des couches
inférieures. Il faut laisser le temps à ces dernières pour s’initialiser. Cela
peut être fait par des boucles d’attente passives, ou par retardement de
l‘initialisation à un instant suffisamment grand. 2.
Ouverture
d’une session entre le client et le serveur Comme nous l’avons annoncé
dans la définition du protocole RTP, ce protocole n’est pas orienté connexion,
c’est donc au serveur de garder un état sur la session comme le nombre de
paquets envoyés, le nom de la source, les paquets perdus, etc. Dans OPNET
Modeler, l’ouverture des sessions et la gestion des différents services au
niveau d’un nœud se fait au niveau de la couche tpal
(transport abstraction layer). Toute
interaction entre application distante par tpal
est organisé en sessions. Tout application ou service
qui est sensé s’exécuter sur le serveur doit s’enregistrer auprès de la couche tpal qui gère une liste des services disponibles
dans un nœud de façon à ce qu’un client qui demande le service par son nom,
soit redirigé vers ce nœud. L’enregistrement se fait par l’appel de la
procédure tpal_service_register (). La figure 17, montre les
étapes nécessaires pour l’ouverture d’une session.
Figure 17. Étapes de l’ouverture d’une session tpal -
Demande de
l’ouverture d’une session passive avec la couche tpal,
par la spécification du nom de l’application, le protocole de transport
utilisé, et le numéro de port. La couche tpal
répond par un message confirmant la réception la demande d’ouverture. -
Le client de son
coté va émettre une demande d’ouverture d’une session active en spécifiant, le
nom du serveur, le nom du service, le numéro de port local, etc. -
La couche tpal du coté
serveur reçoit une indication de demande d’ouverture de session active
(OPEN_IND), cette étape sert pour signaler au serveur d’ouvrir une nouvelle
connexion passive. -
Si l’ouverture de
la session est possible (pas d’erreurs), la couche tpal envoie une confirmation
d’ouverture de session (OPEN_CONFIRM) au serveur -
Une confirmation
est envoyé à la couche tpal
du coté client -
La couche tpal client,
envoie une confirmation d’ouverture de session (OPEN_CONFIRM) à la couche
application. -
La session est
ouverte avec succès et les deux applications peuvent s’échanger des données. Il est nécessaire de rappeler
que toute erreur durant le processus d’ouverture va produire une interruption
d’exécution qui empêchera la simulation de continuer. 3.
Echange de
données entre le client et le serveur La communication entre le
client et le serveur multimédia se fait par l’échange de paquets. Cet échange
se fait par l’utilisation de KP dédiés, qui offrent
une multitude d’options pour l’envoi des paquets. On peut, par exemple, envoyer
un paquet et retarder son envoi d’un instant T qui correspondra à son temps de
traitement. On peut aussi faire en sorte que les paquets soient délivrés sans
causer d’interruption (envoi silencieux). Ces différentes options offrent une
souplesse pour la modélisation d’applications. Afin de différencier les paquets
appartenant à différentes sessions, il faut installer l’ICI
de la session courante avant d’envoyer les paquets. Ainsi, la couche tpal saura à
quelle destination il faut rediriger ce paquet. Dans une application de
demande de multimédia, le serveur se charge de l’envoi des paquets RTP et des
rapports SR (Sender report) et le client se charge de l’envoi des rapports de
réceptions RR. Envoi des paquets RTP du serveur au client et les
rapports SR (Sender report) Si l’étape d’ouverture de la
session s’est bien déroulée, le serveur peut commencer l’envoi des paquets RTP,
voir figure 18. Dans une vraie application de transmission de vidéo les temps
d’envoi des paquets et la taille des paquets sont variables selon le type de payload. Pour simplifier la validation des
modèles développés, nous avons choisi d’utiliser des paquets de taille fixe et
nous avons supposé que l’envoi des paquets se fait dans des laps de temps
suivant une fonction de probabilité simple (constante dans notre cas). On peut
tout de même utiliser l’éditeur de PDF (Probability Density Function) intégré à
Modeler pour créer des distributions de données qui reflètent l’envoi de
données réelles. Le serveur envoie des paquets
de contrôle SR, à des instants fixes (toutes les 5 secondes) pour permettre à
la source de synchroniser les données reçues, en faisant la relation entre le
champ timestamp, et le champ NTP.
Comme on ne s’intéresse qu’à la couche RTP, on n’envoie que le champ qui
spécifie le nombre de paquets envoyés. Envoi des paquets RR par le client vers le
serveur : Le client se charge de la réception des paquets RTP,
de la lecture des différents champs et de la mise à jours des statistiques. Le
client envoie des paquets de contrôle de type RR (receive
report) à des instants fixes afin d’informer le serveur sur la qualité de
réception des données. Modeler permet de déclarer
des statistiques dans le processus modèle de manière à ce qu’il soit possible
de les exploiter par l’intermédiaire d’éditeurs et d’utilitaires de comparaison
de résultats. Chaque statistique sera représentée sous forme de vecteurs
(temps, valeur). Avant d’utiliser une statistique, il faut s’inscrire par
l’appel de la KP op_stat_register(). Cette procédure va renvoyer un handle qui permet de manipuler et de modifier la
statistique. Les différentes variables que
le client met à jour à chaque réception de paquet RTP sont les suivantes :
-
Le nombre paquets
reçus : ce nombre sera incrémenté de 1 à chaque réception de paquets. -
Le nombre paquets
perdus : incrémenté par la différence entre le seq_num
ancien et le seq_num du paquet arrivé. -
Fraction lost : le
nombre de paquets perdus depuis le dernier rapport. Cette variable sera remise
à zéro à chaque envoi de paquet RR et sera incrémentée par la différence entre
les numéros de séquence. -
Jitter (gigue) :
représente les variations dans le temps de transmission des paquets. -
High_seq_num : numéro de séquence le plus grand devient celui du
paquet reçu. La clôture de la session La clôture de la session dans
ce modèle de base sera faite par le serveur après avoir atteint la durée de la
session. Le serveur va envoyer un paquet de contrôle spécial appelé close_session au client puis va appeler la commande
CLOSE_REQ à la couche tpal
pour fermer le session amicalement (attendre que toutes les données soient
arrivées vers leurs destination).
Figure 18. Exemple de processus de base pour le
client.
Figure 19. Exemple de processus de base pour le
Server. Modélisation d’une
application de transmission multimédia à trois tiers Étapes d’une demande de
vidéo dans une application à trois tiers Les mixeurs RTP sont
généralement placés au plus près des clients pour rendre l’adaptation du flux
plus réactive aux changements de la bande passante. Dans ce qui suit sont
décrites les étapes nécessaires pour établir une session de transfert
multimédia à trois tiers (client, mixeur, serveur)
figure 25. Etapes d’une demande de vidéo. Modèles avancés de
client/serveur Au niveau nœud, nous avons
gardé les mêmes modèles de nœuds de la section précédente, cependant nous avons
ajouté 3 types de paquets pour des fonctionnalités de contrôle ; COMMENCE,
ENVOIE et BYE. 1.
ouverture de la
session Dans les modèles proposés
dans la section précédente le client et
le serveur commencent l’envoi des données dès que le
session est ouverte par la couche tpal. Pour permettre plus de contrôle sur les sessions, nous
avons rajouté une étape. Après l’ouverture de la session par la couche tpal, le client
et le serveur se mettent dans l’état prêt. Lorsque le client veut commencer le
transfert, il envoie un paquet ENVOIE au serveur. Ce dernier répond par un
paquet COMMENCE puis commence l’envoi des paquets RTP.
2. Echange des paquets
RTP Le modèle client de la
section précédente, ne permet pas d’envoyer des paquets RTP, cependant ce n’est
pas toujours le cas. Comme dans le cas d’une vidéo conférence, il n’y a pas de communication
client /serveur, mais client/client. Pour cela nous avons rajouté au client la
possibilité d’envoyer des paquets RTP. 3. Envoi des paquets RTCP Lorsque le nombre de clients augmente, le nombre
paquets RR envoyés augmente de manière linéaire et peut dépasser le trafic RTP
injecté dans le réseau, pour cette raison, l’envoi des paquets RTP est limité par
5% de la bande passante de la session. Dont 25% sont réservés pour les rapports
SR (les expéditeurs) et 75% pour les rapports RR (les récepteurs). Ainsi les
temps d’envoi des paquets RR et SR sont calculés comme suit : -
Tsr =nombre d’expéditeurs *taille moyenne du paquet RTCP
/0.5*0.25* débit de la session. -
Trr= nombre de récepteur *taille moyenne du paquet RTCP
/0.5*0.75* débit de la session. 4. Clôture de la session Dans le modèle précédent, c’est le serveur qui
décide de fermer la session lorsque la durée de la session expire. Dans le cas d’une conférence, il faut que tout
client puisse quitter la session sans causer la fermeture de la session. Pour
cela nous avons décidé de prendre en compte le type de paquets BYE. Dans les figures 26 et 27. Sont présentés les nouveaux
processus client et serveur.
figure26. Modèle avancé de client. On remarque dans ce modèle l’apparition de l’état prêt
qui est atteint lorsque la session tpal est ouverte, et que le client est en attente de
l’interruption de début de l’échange de données. Ainsi, le client peut
rejoindre une session ouverte après un temps appelé temps d’arrivée. Le client peut quitter la session après une durée
de session en envoyant un paquet de type BYE.
Figure 27. Modèle avancé de serveur Modélisation du mixeur. 1. Présentation du modèle
nœud du mixeur On peut représenter le modèle
de mixeur en une seule application intégrée dans un module qui reçoit les paquets
de la part du serveur vidéo, fait les traitements nécessaires sur les paquets
puis les fait suivre au client. Nous avons choisi de mettre en oeuvre un architecture plus modulaire composée de trois parties
fonctionnelles (modules indépendants) comme décrit sur la figure 28. -
mixeur_client :
ce module se charge de l’ouverture de la connexion avec un ou plusieurs serveurs,
et le stockages des données dans un buffer. Il
se charge aussi d’envoyer les rapports RTCP au serveur tout au long de la
session. -
mixeur_server : ce
module se charge de la récupération des données du buffer
sur la demande du client. -
buffer : ce module est du type file d’attente. Il permet
de recevoir les paquets envoyés par le module mixeur_client et gère l’envoi de ces derniers au module mixeur_server. Cette décomposition fonctionnelle
facilite l’intégration de nouvelles fonctionnalités dans le mixeur. Par exemple,
si on veut que le mixeur soit capable de faire une conversion du type de payload, on n’a qu’à
mettre une fonction qui permet de convertir le type de paquets au niveau du
module mixeur_server
sans tout de même apporter des modifications sur les modules buffer et mixeur_client. Pour appliquer une nouvelle stratégie pour la
gestion des paquets, on intervient dans le processus qui gère le buffer sans toucher à l’implémentation des deux autres
modules.
Figure 28. Architecture du
nœud mixeur. Présentation
des modèles de processus. Modèle
de processus du module mixeur_client Ce modèle
de processus est presque similaire au modèle client_video_av que nous avons vu
précédemment. Cependant au niveau de l’implémentation, nous avons fait en sorte
que ce modèle soit indépendant du contexte. Les processus mixeur_client et mixeur_server doivent
être crées dynamiquement et ne doivent pas être dépendant du contexte. Les
références aux objets du niveau modules sont transmis en tant que arguments au processus
manager qui est sensé faire la gestion des sessions, et l’arbitrage des interruptions
entre les processus fils.
Figure 29. Modèle de
processus du nœud mixeur_client
Modèle de processus du buffer Pour
modéliser le buffer nous avons utilisé une file
d’attente de type pf_fifo
(passive flowthrough,
first in first out). Ainsi,
les paquets qui arrivent dans la file ne seront envoyés que sur la demande du mixeur_serveur.
De plus, ce type de file permet de créer des sous files à la demande contrairement
aux autres files dites concentrative, et qui rassemblent toutes les
données en entrée dans une seule file. Le processus modèle de cette file est
simple et permet l’implémentation de
stratégies de priorités selon le besoin de l’application.
Figure 30. Modèle de
processus du buffer Modèle de processus du module mixeur_server Ce modèle
de processus intègre toutes les fonctionnalités du serveur_vidéo_av. Il permet de
récupérer des données du buffer et les envoyer aux clients
demandeurs. Il est possible d’intégrer la fonction d’adaptation de flux dans ce
module. Lorsque le processus mixeur _server reçoit le rapport RR, il lit les champs fraction
lost et variation de la gigue puis décide
d’envoyer ou non les flux d’amélioration au client. Le serveur n’élimine pas
tous les flux d’amélioration dès qu’il reçoit le premier rapport RR signalant
des pertes. Il agit de manière progressive selon l’ordre décroissant de la
qualité d’amélioration.
Figure 31. Le modèle du processus mixeur_server
|
