Simulateur Interactif de QoS

1. Simulateur Interactif de QoS Master Informatique 2011 UNIVERSITE AVIGNON 2010/2011 Tuteur : Etudiants : Hayel Yezekael El-Malki Mohamed Marie Pinet Tannicha Abdessamad Tabarine Youssef

Remerciements Nous tenons à exprimer ma profonde reconnaissance à Monsieur Yezekael HAYEL, tuteur de notre projet qui a dirigé notre travail; ses conseils, ses orientations ainsi que sa patience ont été des éléments primordiaux de la réussite de ce projet. 2

I Sommaire 1. Remerciements... 2 I Sommaire... 3 II. Introduction et problématique... 5 1. Avant propos... 5 2. Objectifs du projet... 5 3. Objectif de la simulation... 6 A. Les domaines de la simulation... 6 B. But de la simulation... 6 III. Exemple de Simulateur de QoS... 7 1. NS2... 7 2. OPNET... 7 IV. Etude de la Qualité de Service... 8 1. Notion de qualité de service «QoS»... 8 2. Niveaux de service... 9 3. Caractéristiques... 9 A. Mise en forme du trafic... 10 4. Paramètres importants pour une meilleur qualité de service... 11 A. La qualité de service au niveau applicatif... 11 B. La qualité de service de réseau... 11 C. La qualité de service "de bout en bout... 11 D. La perte de paquets... 12 E. La latence... 12 F. La gigue... 12 G. La bande passante... 12 H. L intérieur du réseau... 12 I. L extérieur du réseau... 13 V. Gestion de la qualité de service... 13 1. Architecture d un routeur supportant la qualité de service... 13 2. Gestion des files d attente... 14 A. Prévention de la congestion : Politique RED - WRED... 14 a. RED -WRED... 14 B. La gestion de la congestion... 15 C. Modèles IntServ et DiffServ... 17 VI. Enoncé des besoins... 18 VII. Le simulateur... 19 1. Les paramètres Fixes... 19 2. Les paramètres Variables... 19 VIII. Conception du simulateur... 20 1. Choix du langage... 20 2. Choix de l outil de développement... 20 3. Diagramme du classe... 20 IX. Fonctionnement du logiciel... 22 3

1. Diagramme des cas d utilisation... 22 2. Teste de fonctionnement... 23 3. Diagrammes de séquence... 25 A. Lancement de simulation... 25 B. Changement du débit... 25 C. Historique... 26 4. Planning et répartition des taches... 27 X. Bilan et Perspectives... 29 XI. Conclusion... 29 4

II. Introduction et problématique 1. Avant propos La quantité d information qui circule dans nos réseaux est devenue très importante, les routeurs, qui sont les points névralgiques du réseau Internet, sont eux qui priorisent, filtrent, et dirigent les flux Internet qui évolue rapidement en termes de taille mais également en termes d'architecture et de topologie. Aujourd'hui dans l'internet, la retransmission des paquets due à une expiration des horloges, la perte de paquets ou encore à la taille limitée des files d'attente sont les différentes causes de la congestion au niveau des routeurs. Cette congestion sera par la suite la cause de longs délais de bout en bout. Ce service ne peut pas assurer une qualité de service suffisante pour des applications qui auraient des contraintes temporelles. Les entreprises sont conscientes des coûts énormes que peut provoquer un système qui présente des problèmes de performances après le déploiement ; C est d ailleurs pour cette raison qu elles dépensent beaucoup de temps, d énergie et d argent pour valider leurs applications. Modéliser un système virtuel de façon interactive, observer les principaux concepts associés à fin d évaluer ses performances et prévoir le comportement le déploiement physique, permet de disposer d un réseau robuste, performant et aussi faire un gagne de temps et d argent important. 2. Objectifs du projet Le but de ce projet est de proposer un simulateur interactif qui permet d étudier des mécanismes comme la gestion des priorités ou le partage équitable des ressources dans un routeur. Le routeur sera modélisé par des files d'attente en mode paquet. L'objectif est de réaliser une application qui permet de contrôler en temps réel les paramètres du routeur et du trafic. 5

3. Objectif de la simulation A. Les domaines de la simulation Des activités peuvent être effectuées dans le domaine physique ou dans le domaine virtuel. -Le domaine virtuel : Ce domaine est celui de la simulation du comportement du produit virtuel. Simuler dans le domaine virtuel consiste à modéliser le comportement du produit soumis à des sollicitations de son environnement de manière à prévoir par un calcul le comportement du produit en utilisation. Le comportement du produit est caractérisé par des grandeurs virtuelles issues d un calcul. -Le domaine de mesure : Ce domaine est celui de la simulation du comportement d une maquette physique du produit. Simuler dans le domaine physique ou mesurer consiste à prévoir le comportement du produit en utilisation par la mesure de grandeurs physiques sur un modèle physique du produit soumis à des sollicitations de son environnement. B. But de la simulation La simulation à pour objectif de recréer de façon conforme à la réalité les perturbations de l environnement. En simulant les conditions réseau et le volume de données généré par l application, il est possible d avoir une vision très complète sur les performances en de différentes caractéristiques réseau. La simulation c est un processus qui consiste en : - La conception un modèle du système (réel) étudié, - L évaluation des performances de ce système - Analyse des observations fournies par le déroulement du modèle et formulation des décisions relatives au système. Le but général est de comprendre le comportement dynamique du système, de comparer plusieurs configurations, d évaluer différentes stratégies de pilotage, d évaluer et d optimiser des performances. Dans notre cas, notre simulateur a pour but de simuler la qualité de service (QoS) dans un routeur. 6

III. Exemple de Simulateur de QoS 1. NS2 NS est un outil logiciel de simulation de réseaux informatiques. Il est essentiellement élaboré avec les idées de la conception par objets, de la réutilisation du code et de modularité. Il est aujourd'hui un standard de référence en ce domaine, plusieurs laboratoires de recherche recommandent son utilisation pour tester les nouveaux protocoles. Le simulateur NS actuel est particulièrement bien adapté aux réseaux à commutation de paquets et à la réalisation de simulations de grande taille (le test du passage à l'échelle). Il contient les fonctionnalités nécessaires à l'étude des algorithmes de routage unicast ou multicast, des protocoles de transport, de session, de réservation, des services intégrés, des protocoles d'application comme FTP. Les principaux composants actuellement disponibles dans NS par catégorie sont : application : Web, ftp, Telnet, générateur de trafic (CBR...) ; transport : TCP, UDP, RTP, SRM ; routage unicast : Statique, dynamique (vecteur distance) ; routage multicast : DVMRP, PIM ; gestion de file d'attente : RED, DropTail, Token bucket. Prises ensembles, ces capacités ouvrent le champ à l'étude de nouveaux mécanismes au niveau des différentes couches de l'architecture réseau. NS est devenu l'outil de référence pour les chercheurs du domaine. Ils peuvent ainsi partager leurs efforts et échanger leurs résultats de simulations. Cette façon de faire se concrétise aujourd'hui par l'envoi dans certaines listes de diffusion électronique de scripts de simulations NS pour illustrer les points de vue. 2. OPNET OPNET (Optimum Network Performance) est une famille des logiciels de modélisation et de simulation de réseaux s'adressant à différent public tel que les entreprises, les opérateurs et la recherche... OPNET IT Guru est la version académique de cette famille il offre la possibilité de dessiner et d'étudier. IT GURU se base sur le fait qu'opnet est l'un des meilleurs logiciel de simulation de réseaux présent sur le marché, le seul problème d'opnet c'est qu'il est payant mais ce problème est résolu avec la version académique. 7

Opnet permet de construire des simulations d infrastructure réseau. Le logiciel est composé de différents éditeurs : le module «node» qui sert à définir le fonctionnement d un nœud d un réseau construit grâce au «Project editor» mais dans le cadre de notre simulation, il sert à simuler l ensemble du réseau. Le module «process» qui définit normalement la machine à états d un élément du nœud mais, dans notre cas le protocole «IP mobile» à l échelle du réseau. L ensemble de ce protocole est codé en C en utilisant des packages fournis par Opnet (gestion des graphes, algorithme de Dijkstra ). IV. Etude de la Qualité de Service 1. Notion de qualité de service «QoS» Le terme QoS (acronyme de «Quality of Service», en français «Qualité de Service») désigne la capacité à fournir un service (notamment un support de communication) conforme à des exigences en matière de temps de réponse et de bande passante. C est l ensemble des mécanismes mis en œuvre permettant l utilisation optimale des ressources partagées, en ordonnançant le partage des ressources entre les différents types d applications véhiculées par le réseau. Appliquée aux réseaux à commutation de paquets (réseaux basés sur l'utilisation de routeurs) la QoS désigne l'aptitude à pouvoir garantir un niveau acceptable de perte de paquets, défini contractuellement, pour un usage donné (voix sur IP, vidéoconférence, etc.). En effet, contrairement aux réseaux à commutation de circuits, tels que les réseaux téléphonique commuté, où un circuit de communication est dédié pendant toute la durée de la communication, il est impossible sur internet de prédire le chemin emprunté par les différents paquets. Ainsi, rien ne garantit qu'une communication nécessitant une régularité du débit puisse avoir lieu sans encombre. C'est pourquoi il existe des mécanismes, dits mécanismes de QoS, permettant de différencier les différents flux réseau et réserver une partie de la bande passante pour ceux nécessitant un service continu, sans coupures 8

2. Niveaux de service Le terme «niveau de service» définit le niveau d'exigence pour la capacité d'un réseau à fournir un service point à point ou de bout en bout avec un trafic donné. On définit généralement trois niveaux de QoS : -Meilleur effort (en anglais best effort), ne fournissant aucune différenciation entre plusieurs flux réseaux et ne permettant aucune garantie. Ce niveau de service est ainsi parfois appelé lack of QoS. -Service différencié permettant de définir des niveaux de priorité aux différents flux réseau sans toutefois fournir une garantie stricte. - Service garanti (en anglais guaranteed service ou hard QoS), consistant à réserver des ressources réseau pour certains types de flux. Le principal mécanisme utilisé pour obtenir un tel niveau de service est RSVP (Resource reservation Protocol, traduisez Protocole de réservation de ressources). 3. Caractéristiques Dans un réseau, les informations sont transmises sous la forme de paquets, petits éléments de transmission transmis de routeur en routeur jusqu'à la destination. Tous les traitements vont donc s'opérer sur ces paquets. La mise en place de la qualité de service nécessite en premier lieu la reconnaissance des différents services. Celle-ci peut-se faire sur la base de nombreux critères : La source et la destination du paquet. Le protocole utilisé (UDP/TCP/ICMP/etc.). Les ports source et de destination dans le cas des protocoles TCP et UDP. La date et l'heure. La congestion des réseaux. La validité du routage (gestion des pannes dans un routage en cas de routes multiples par exemple). La bande passante consommée. Les temps de latence. En fonction de ces critères, différentes stratégies peuvent ensuite être appliquées pour assurer une meilleure qualité de service. 9

A. Mise en forme du trafic Mettre en forme un trafic signifie prendre des dispositions pour s'assurer que le trafic ne dépasse jamais certaines valeurs prédéterminées. Pratiquement, cette contrainte s'applique en délayant certains paquets pour forcer un certain trafic, selon divers algorithmes. Le contrôle du trafic peut-être utile pour limiter l'engorgement et assurer une latence correcte. Par ailleurs, des limitations de débits séparément aux trafics permettent en contrepartie de leur assurer en permanence un débit minimum, ce qui peut être particulièrement intéressant pour un fournisseur d'accès par exemple, souhaitant garantir une certaine valeur du débit à ses clients. Les deux algorithmes les plus utilisés sont : Le seau percé (Leakybucket). Le trafic entrant dans la file (le seau) est régulé pour sortir à débit constant sur le réseau. La taille du seau et le débit en sortie sont configurables par l'utilisateur. La taille étant déterminante en ce qui concerne les pertes de paquets (lorsque le seau est plein le trafic entrant peut être jeté). Figure 1. Le seau à jetons ((Token bucket). Le trafic ne traverse pas directement le seau mais est transmis sur la base de jetons présents dans le seau. Un jeton correspond à un nombre de bits donnés, le taux d'arrivée des jetons correspond au débit moyen et la profondeur du seau à la taille de la rafale. Ce mécanisme permet à un trafic en rafale d'être transmis tant qu'il y a des jetons dans la file d'attente, ceux-ci ayant pu être accumulés en situation de réseau peu chargé. 10

Figure 2. 4. Paramètres importants pour une meilleur qualité de service A. La qualité de service au niveau applicatif On entend souvent parler d'accords sur la qualité de service (SLA : Service Level Agreement) ou de gestion des niveaux de service (SLM : Service Level Management). Mais derrière le terme de "qualité de service" (QoS : Quality of Service) se cachent des paramètres à la fois très divers et précis, qui reposent sur un nombre non négligeable d'indicateurs et de notions à prendre en considération. On parle parfois de QoS au niveau applicatif, ce qui désigne la qualité perçue par l'utilisateur final. Les critères d'appréciation sont donc plutôt subjectifs, même si certains événements tels que les pannes ou les erreurs sont directement perceptibles et peuvent être évalués de manière rigoureuse. B. La qualité de service de réseau Au sein d'un réseau donné, la qualité de service est évaluée en fonction des différents équipements qui le composent, des règles qui y ont été définies, du trafic qui y circule, etc. C. La qualité de service "de bout en bout Derrière cette expression, qui signifie que la qualité de service est théoriquement la même d'un bout à l'autre d'un réseau, on trouve une multitude de situations, notamment conditionnées par la pluralité des opérateurs et des matériels présents, 11

ainsi que des capacités réseau et des politiques de qualité de service en place. Certains nœuds de redistribution peuvent dans ce cas être sources d'engorgement. D. La perte de paquets La perte de paquets correspond aux octets perdus lors de la transmission des paquets. S'exprime en taux de perte. E. La latence C'est le délai de traversée du réseau, d'un bout à l'autre, par un paquet. Les différentes applications présentes sur ce réseau n'auront pas le même degré d'exigence en fonction de leur nature : faible, s'il s'agit d'une messagerie électronique ou de fichiers échangés, ce degré d'exigence sera fort s'il s'agit de donnés "voix". La latence dépend du temps de propagation (fonction du type de média de transmission), du temps de traitement (fonction du nombre d'équipements traversés) et de la taille des paquets (temps de sérialisation). F. La gigue Désigne les variations de latence des paquets. La présence de gigue dans les flux peut provenir des changements d'intensité de trafic sur les liens de sorties des commutateurs. Plus globalement, elle dépend du volume de trafic et du nombre d'équipements sur le réseau. G. La bande passante Il existe deux modes de disponibilité de la bande passante, en fonction du type de besoin exprimé par l'application. Le mode "burst" est un mode immédiat, qui monopolise toute la bande passante disponible (lors d'un transfert de fichier par exemple). Le mode "stream" est un mode constant, plus adapté aux fonctions audio/vidéo ou aux applications interactives. H. L intérieur du réseau Afin d'arbitrer entre les modes "burst" et "streaming" précédemment cités, une gestion du trafic peut soit être installée au sein du réseau, soit à ses extrémités. S'il s'agit de l'intérieur du réseau, les nœuds de ce réseau opèrent alors comme autant d'éléments de classification et de priorisation des paquets qui y circulent. 12

I. L extérieur du réseau Si, en revanche, le dispositif se trouve à l'extérieur, les équipements constituant le réseau se trouvent déchargés de toute QoS. Deux mécanismes sont alors à l'œuvre : le contrôle de débit TCP, qui modifie le débit des applications TCP en fonction des conditions de charge du réseau et du niveau de priorité des applications, et la gestion des files d'attente personnalisées, qui affecte les flux entrants aux files d'attentes qui leur correspondent. V. Gestion de la qualité de service 1. Architecture d un routeur supportant la qualité de service Figure 3. La figure 3 présente l architecture d un routeur gérant la QoS. On peut remarquer qu en plus de router les paquets vers la bonne interface de sortie (fonction de routage), ce type de routeur comporte un système de file d attente sur chaque interface de sortie et un ordonnanceur permettant de choisir les paquets qui seront envoyées. C est grâce au marquage des paquets que ces derniers sont placées dans les files d attente logicielles pour finalement être placées dans une file matérielle après l ordonnancement. 13

2. Gestion des files d attente Quelle que soit la politique de QoS mise en œuvre, c est toujours au niveau des files d attente des routeurs que cette politique est appliquée. Par d faut, dans la politique de l Internet best-effort, tous les paquets arrivant dans le routeur sont placés dans une file d attente FIFO. Cela permet de traiter tous les flux de la même manière. Il existe deux méthodes permettant de traiter les paquets d une manière plus évoluée, la prévention de la congestion et la gestion de la congestion. C est que nous allons détailler A. Prévention de la congestion : Politique RED - WRED A fin de prévenir une éventuelle congestion, les routeurs détruisent des paquets aléatoirement, ce qui permet une régulation naturelle en profitant du mécanisme présent dans le protocole TCP. En effet, lorsqu un paquet est perdu, l metteur ne reçoit pas d acquittement de la part du récepteur et ralentit donc son mission. Le problème est que cela produit un ph nom`ne d oscillation étant donné que les metteurs augmentent ou réduisent leurs d bits en même temps a. RED -WRED Pour pallier au problème de la congestion, le mécanisme RED détecte la congestion avant que des pertes apparaissent en contrôlant le remplissage des files d attente. Le principe de l algorithme RED (Random Early Detection) consiste à prévenir les congestions. Lorsque la file d attente commence à être saturée, des paquets correspondant à des flux sélectionnés aléatoirement sont rejetés, ce qui permet une régulation naturelle en profitant du mécanisme présent dans le protocole TCP. Figure 4. 14

Algorithme RED : Dans RED les paquets sont détruits aléatoirement, ce qui ne permet pas de différencier les types de flux. Le mécanisme WRED (Weighted RED) vient combler cette lacune en tenant compte de la priorité des paquets puisqu il possède un seuil pour chaque file correspondant à une classe de trafic. WRED permet de sélectionner les flux, en fonction de priorités qui déterminent le rejet des paquets. B. La gestion de la congestion Pour gérer les paquets reçus et les transmettre, un routeur devra forcément employer une ou plusieurs files d attente. L ordonnancement et la gestion des files d attente conditionne grandement les performances des routeurs et constitue un élément important de la QoS. L'ordonnancement désigne l'ensemble des méthodes visant à modifier l'ordre de départ des paquets, en remplacement de la règle du «premier arrivé, premier servi». Une de ses applications les plus courantes consistera ainsi à donner priorité à certains types de trafic, de façon sommaire en ne laissant passer du trafic de faible priorité que s'il n'y a plus de trafic de forte priorité, ou de façon plus fine avec des algorithmes de Round-Robin pondérés, visant à faire passer des paquets des différentes connexions tour à tour, en laissant plus de temps aux paquets prioritaires. Une autre application, le Fair Queuing consiste à séparer nettement les connexions, et à leur attribuer successivement et équitablement une possibilité de faire passer leurs paquets, cela permet de s'assurer qu'aucune application, même très demandeuse de débit, n'en écrasera d'autres. Lors d un fonctionnement sans congestion, la mise dans des files d attente des paquets après classification n est d aucune utilité car l ordonnanceur du routeur pourra traiter tous les paquets. Cela dit, en cas de congestion l intérêt est tout autre. 15

En effet, en fonction de l algorithme de gestion des files d attente choisi, l ordonnanceur pourra vider préférentiellement une file et laisser une file moins prioritaire se remplir et donc rejeter des paquets. Nous allons voir ici les algorithmes de gestion de files d attente les plus courants. -PQ (Priority Queueing) Cet algorithme est le plus simple à mettre en place. Il permet d affecter une priorité stricte d une file d attente. La file possédant la priorité la plus élevée est toujours servie en premier, une file est servie uniquement lorsque toutes les files de priorités supérieures sont vides Cet algorithme est intéressant pour gérer le trafic critique mais ne doit pas être utilisé pour un nombre important de flux, car les flux non prioritaires seraient systématiquement rejetés. Risque d affamer les flux de faibles priorités si l intensité de trafic des flux les plus prioritaires est supérieure à la capacité du serveur. Figure 5 : exemple ordonnanceur PQ -FQ (Fair Queueing) Cet algorithme permet le partage équitable des ressources. Si deux files d un routeur utilisent FQ, les flux passant dans chaque file auront le même débit en cas de congestion. -WFQ (Weighted Fair Queueing) WFQ est identique à FQ mais il permet de pondérer certains flux. Il est ainsi possible de diviser la bande passante entre plusieurs files. WFQ est relativement coûteux en ressource car le routeur doit calculer à chaque émission combien de paquets de chaque file seront émis. Dans notre cas, nous avons opté pour le Fair Queueing, car c est le plus abordable pour notre application. 16

C. Modèles IntServ et DiffServ i. IntServ Integrated Services (IntServ) consiste à fournir une QoS garantie stricte sur les réseaux IP. Dans un modèle IntServ, les applications envoient une requête RSVP à fin de réserver les ressources réseau nécessaires. Apres une négociation avec les gestionnaires de QoS déterminant si le service peut être garanti, les ressources sont réservées ou alors un message d erreur est renvoyé au demandeur. Une fois les ressources réservées, la QoS pourra être appliquée dans les routeurs avec des algorithmes de gestion de files d attente. Le but principal de IntServ est de fournir un lien de communication à qualité constante en termes de débit et de délai. La principale limitation de IntServ réside dans son passage à l échelle. En effet, les requêtes RSVP doivent être mémorisées dans tous les routeurs concernés. Or dans un réseau à large échelle tel qu Internet, il y a une quantité phénoménale de flux concurrents. Une telle quantité imposerait des stockages très conséquents dans la mémoire des routeurs, ce qui engendrerait un surcout inconcevable. ii. Diffserv Le modèle à différentiation de Services (DiffServ) ajoute des nouvelles fonctionnalités aux routeurs de l Internet afin d améliorer la Qualité de Service offerte aux flux. Des contraintes telles que la réduction du délai d acheminement ou le contrôle dans la distribution de ressources peuvent être satisfaites grâce aux mécanismes proposés par ce modèle. A travers le Comportement Assuré, le modèle DiffServ introduit le concept d élimination sélective basée sur un niveau de priorité. D un coté, cette notion peut être exploitée pour distribuer équitablement les ressources réseau indépendamment du comportement des sources. De l autre, en utilisant des algorithmes de codage audio/vidéo multi-couches, la notion de priorités peut réduire considérablement l effet de pertes sur la transmission de flux multimédia. Figure 6. fonctionnement rsvp 17

VI. Enoncé des besoins Le besoin de l'utilisateur est l'interactivité du simulateur. Celle-ci lui permettra de voir, en temps réel, l'évolution du trafic sur le réseau par rapport à différents critères (débit,...). Grâce à la constante évolution des moyens de calculs, les simulations numériques deviennent de plus en plus complexes. Il n est pas rare de trouver différents modèles et codes couplés sur un réseau hétérogène (e.g. les simulations multi-physiques). Même si les enjeux de la simulation interactive sont aujourd hui bien perçus, la communauté e du calcul scientifique exprime toujours le besoin d une nouvelle génération d outils pour le pilotage des simulations numériques sur des environnements distribués comme la grille. Le domaine de la simulation interactive ou «computational steering» a pour but d améliorer le processus de simulation numérique (modélisation, calcul, analyse) en le rendant plus interactif. Dans cette approche, l utilisateur n attend plus passivement les résultats de la simulation, mais il visualise en temps-réel l évolution des données calculées et peut interagir tout au long de la simulation en pilotant les algorithmes ou en modifiant certains paramètres à la volée. Un tel outil peut s avérer tr`es utile aux scientifiques pour la compréhension des phénomènes modélisés et la détection d erreurs dans le cas des simulations longues. Un environnement de pilotage est défini dans comme une infrastructure de communication couplant une simulation avec une interface utilisateur, appelé système de pilotage, qui offre classiquement des moyens de visualisation et d interaction avec la simulation, nous avons donc réalisé une interface graphique qui nous permet de simuler en temps réel notre processus en contrôlant les paramètres( débit par exemple) cette interface prend en compte les modification des paramètres et par conséquent affiche la simulation en temps réel. 18

VII. Le simulateur 1. Les paramètres Fixes Lors de la conception de notre application, nous avons décidé d avoir certain paramètre, fixes, enregistré dans l application et dont l utilisateur ne peut pas agir, ou définit une foi sans pouvoir changer, ces paramètres sont les suivant : Avant le lancement, l'utilisateur pourra définir la taille des paquets qui seront transmis durant la simulation. Cela influera donc sur le temps de traitement. - Le nombre de files d attente - La taille des files d attente Donc dans notre application, le routeur gère une file d attente, et la taille de la file d attente est entrée une fois lors du lancement de l application Avant le lancement, l'utilisateur pourra définir la taille de la fille d'attente du routeur. 2. Les paramètres Variables Nous avons aussi des paramètres variables dont l utilisateur peut choisir et modifier a tout moment, a savoir : -Le temps de traitement. - Le Débit Concernant le temps de traitement des paquets, il est exprimé en bit/s, il est calculé grâce à la taille des paquets, définit par l'utilisateur, et du débit descendant moyen de la France (7485,44 Kb/s). Pour le débit, il est choisit par l utilisateur avant lancer l application, et à tout moment pendant la simulation il peut faire varier ce débit. 19

VIII. Conception du simulateur 1. Choix du langage Pour la réalisation de notre simulateur, nous avons choisi de le faire en langage java. En effet le java est un langage que nous avons vu durant notre cursus, de plus le java est un langage simple est robuste, simple car il n'utilise qu'un nombre restreint de nouveaux concepts. L'un des gros avantages du langage JAVA est sa portabilité. La portabilité signifie que notre programme écrit une seule fois fonctionnera sur une grande quantité de plateformes différentes, sans nécessiter une quelconque modification du code. Même la programmation graphique, réseau et système est totalement indépendant des machines et systèmes, c est exactement le langage le mieux adapté pour notre application. 2. Choix de l outil de développement Comme nous avons choisi de développer en langage java, avons opté pour l outil de développement Eclipse. C est un environnement de développement intégré libre extensible, universel et polyvalent, permettant de créer des projets de développement mettant en œuvre n'importe quel langage de programmation. 3. Diagramme du classe La figure 7 représente le diagramme des Classes de notre application : L architecture de notre application se compose en cinq classes : -Courbe. -Générateur de trafique. -Routeur. -Frame1 -SimulateurQos. Les autres Classe que nous apercevons correspondent à des threads créer lors de l exécution du programme, qui corresponde aux différentes actions qu implémente le programme 20

Figure 7 Class Diagram 21

IX. Fonctionnement du logiciel Lorsque l'utilisateur lance le simulateur, celui-ci va générer (dans des tableaux) : Les valeurs aléatoires que l'on utilisera pour la gestion des parquets: -les temps d'attente des paquets dans la file, -les temps de sortie des paquets de la file, -les temps de séjour des paquets dans la file (temps d'attente + temps de traitement). Ces tableaux seront ensuite régénérés si le simulateur arrive à la fin des tableaux et que l'utilisateur n'a fait aucune une modification du débit, et se régénère aussi à chaque fois que l'utilisateur fait une modification du débit. 1. Diagramme des cas d utilisation Figure 8 use case diagram 22

2. Teste de fonctionnement L utilisateur peut effectuer plusieurs opérations : Tout d abord, il peut lancer l application en cliquant sur le bouton «start» à partir de l interface graphique, Figure 9. Interface Une foi la simulation lancée l utilisateur pourra voir l avancement du traitement sur le graphique, il peut arrêter la simulation en cliquant sur le bouton «stop». Figure 10. Lancement de simulation 23

Le débit est positionné sur la valeur 12 Mbit/s, nous apercevons une courbe croissante. L utilisateur peut à tout moment changer la valeur du débit, visible sur l interface graphique, pour voir les variations apportées. Figure 11. Variation après changement de débit Apres modification du débit, il a été baissé de 12 à 4 Mbit/s, on remarque une chute du nombre de paquet dans la file d attente, ce qui est tout à fait normal. Sur la barre «progression de la file» on trouve le niveau de remplissage de la file d attente. Un clique sur le bouton «quitter» arrête la simulation est quitte le programme. 24

3. Diagrammes de séquence A. Lancement de simulation Figure 12. sequence diagram play B. Changement du débit Figure 13. sequence diagram debit 25

C. Historique Figure 14 sequence diagram historique 26

4. Planning et répartition des taches Figure 15. Gantt diagram 27

Figure 16. Gantt diagram 28

X. Bilan et Perspectives Notre objectif durant ce projet a été de réaliser une application fonctionnelle qui réponde aux termes définis dans le cahier des charges du premier semestre. À ce stade, certes nous n avons pas mené à terme toutes les exigences : gestion d un nombre important de files d attente, aspect visuel, quantité de données récoltée, mais nous avons réussi à implémenter au mieux tous les points importants pour une simulation convenable. Ce logiciel permet de simuler en temps réel la QoS d'un routeur et la gestion de sa file d attente, il permet aussi de sauvegarder le trafic dans un fichier d'historique qui aide ensuite l'utilisateur pour faire les diagnostics. De plus le fait que le logiciel soit développé en Java, cela fait de lui une application portable, et donc exécutable sous tous les système d exploitations. XI. Conclusion Projet a été une expérience très enrichissante et bénéfique pour nous. Il nous a permis d'approfondir nos connaissances, d'augmenter mes capacités intellectuelles, et de découvrir beaucoup de choses, ce qui est profitable pour notre culture générale. Il nous a permit également de nous projeter dans notre future vie professionnelle en nous sortant du cadre purement scolaire. Il nous a confrontés à un certain nombre de contraintes que nous pouvons rencontrer dans le milieu du travail. La gestion du projet, l organisation au sein de celui-ci, les comptes rendus mensuels nous ont également permis de prendre du recul sur l avancement des travaux dans le temps. De plus nous avons pu apprendre davantage sur le travail au sein d une équipe et ainsi appréhender l aspect humain, écouter les autres, défendre nos idées, se partager le travail et à prendre des initiatives. Pour mener à bien notre projet il nous a fallu acquérir de la persévérance et la patience. Se confronter à la réalité des choses nous a fait nous heurter à des difficultés nouvelles et inattendues. Nous avons donc progressé sur le plan des compétences, du savoir, et également sur le travail et les connaissances acquises tout au long de l année. Pour conclure nous pouvons affirmer que ce projet nous prépare de la meilleure façon qu il soit à la vie professionnelle, tout en nous donnant un sens accru des responsabilités. 29