previous up next contents index Projet de fin d'année Logiciel
< Ingénierie de la solution < > Bilan >

Sous-sections

Mise en oeuvre


Paquetage du produit

Le projet initial que nous reprenons était très loin d'un système logiciel livrable. Nous avons essayé de l'améliorer dans cette direction en le rendant plus portable, plus modulaire, et en le documentant.

Automatisation de la compilation

A l'origine la compilation était assez laborieuse dès qu'on sortait de l'environnement des développeurs. Afin de la simplifier, nous avons utilisé autoconf et automake. Le logiciel se compile et s'installe maintenant avec le classique ./configure && make && make install.

Généralisation de l'implémentation


Données d'entrée

Nous avons supprimé les spécificités au réseau actuel de l'ENSEIRB en particulier au niveau de la liste des machines à interroger et de la base initiale de correspondances entre les noms ou les IPs et les adresse MAC.

En effet, il existe différentes sources donnant accès à ces informations, mais elles ne sont pas toutes disponibles sur tous les systèmes. Par exemple, à l'ENSEIRB on peut se servir de la base NIS pour avoir d'une part la liste des machines du réseau et d'autre part leurs adresses physiques (MAC). A l'origine, la récupération était codée en dur dans le logiciel qui n'était pas utilisable sans modification sur un réseau où les tables NIS correspondantes ne sont pas présentes.

Pour permettre une utilisation de notre logiciel sur le plus grand nombre de réseau, nous avons choisi de fournir ces listes indispensables au fonctionnement du logiciel dans des fichiers dont les chemins sont passés sur la ligne de commande. Nous avons écrit des scripts sh/perl pour créer ces listes dans le cas de la base NIS de l'ENSEIRB. Nous avons aussi écrit des scripts semblables utilisables sur n'importe quel réseau faisant tourner arpwatch3.1Les deux jeux de scripts sont utilisables à l'ENSEIRB puisqu'arpwatch y tourne également. Nous avons choisi d'écrire des scripts sh/perl car ils sont bien adaptés pour ce travail. De plus, un utilisateur quelconque peut les modifier facilement pour les adapter à son réseau sans avoir à plonger dans le code de notre application.


Modularité

Comme nous l'avons décrit dans l'analyse, le code repris présentait de graves problèmes de structuration qui nuisaient à la maintenabilité et à la lisibilité, nous avons donc essayé d'y remédier.

La quasi totalité du logiciel a été reprise afin de l'organiser en modules logiques. Cette refonte a été effectuée de manière incrémentielle afin de pouvoir faire des tests de non regression à chaque étape. Nous nous étions posé la question de l'éventuel intérêt de refaire complètement certaines parties à partir de zéro après l'analyse du code. Nous n'avions pas choisi cette possibilité en particulier parce qu'on risquait de ne pas pouvoir finir une application avec au moins autant de fonctionnalités que celle d'origine; compte-tenu des gros dépassements sur nos prévisions de départ en particulier pour ce qui concerne la prise en charge des réseaux virtuels, ce choix s'est avéré judicieux.


Documentation du produit

Nous avons documenté le logiciel et pour l'utilisateur et pour le mainteneur. Ces deux documentations ont été rédigées en anglais (de même que l'ensemble des commentaires des sources et des noms de variable) afin que l'utilisation et l'évolution du logiciel ne soit pas limitée aux francophones; ceci nous semblait assez important dans l'optique logiciel libre, surtout qu'il n'existe quasiment pas d'autres logiciels libres avec ses fonctionnalités.

Pour l'utilisateur

Un user manual a été rédigé pour expliquer les fonctionnalités de l'application. Il donne les prérequis et explique comment compiler et utiliser les programmes c'est à dire l'application de collecte et l'interface graphique.

Pour le mainteneur

D'autre part, nous avons rédigé un maintainer manual à l'usage des futures personnes qui pourraient être amenés à effectuer des développements sur l'application. Il décrit l'organisation des sources (la logique du découpage de nos modules). Il présente aussi certains points délicats comme l'algorithme de fusion des arbres ou l'heuristique de ventilation des forwarding lists par réseau virtuel.

Nous avons aussi documenté précisément la partie sur la récupération des informations concernant la configuration des réseaux virtuels; en effet la localisation de ces informations nous a pris beaucoup de temps et mérite un récapitulatif.

Prise en charge VLANs


Manque de standardisation

Si les informations générales que l'on peut récupérer par SNMP comme la liste des interfaces, leurs adresses, etc. sont très standards, les choses se gâtent un peu pour ce qui concerne les VLANs.

Les informations récupérables par SNMP sont organisées de façon arborescente. Chaque noeud de l'arborescence contient une valeur (qui peut être de différents types). Les RFCs définissent la signification des différents n\oeuds. Cependant, les informations relatives aux VLANs ne sont pas toujours implémentées de la manière décrite dans la RFC correspondante [13].

En conséquence, il y a eu un travail de recherche de la localisation des informations assez important car il fallait le faire pour chaque type d'équipement. Une fois que l'on savait où trouver les différents éléments de la configuration des réseaux virtuels pour chaque équipement, nous avons implémenté leur récupération de la manière suivante: on commence par récupérer le type d'équipement (une chaîne décrivant l'équipement est récupérable par SNMP, elle comporte en général le constructeur et la référence de la machine), ensuite suivant le type de l'équipement, on récupère l'information à la bonne ``adresse''.

Comme il s'agit d'un élément du logiciel qui a de grande chance de poser des problèmes lors de l'utilisation d'équipements différents de ceux utilisés à l'ENSEIRB actuellement, nous avons veillé à bien documenter ceci pour que des tiers puissent facilement adapter le logiciel à d'autres marques ou modèles de commutateurs.


Défaut d'analyse

Un autre point intéressant pédagogiquement parlant a été une mauvaise analyse de notre part des informations à notre disposition. Sur certains équipements, les forwarding lists sont récupérées ventilées par réseau virtuel. Sur d'autres elles sont récupérés globalement mais on peut aussi récupérer la configuration du matériel (c'est-à-dire à quel VLAN appartient chaque port, et sur quel VLAN il taggue les paquets non taggués provenant d'un port donné). Nous pensions que cette information était suffisante pour ventiler les différentes adresses des forwarding lists mais en réalité cela oblige à mettre en place une heuristique assez délicate: il faut savoir où les paquets sont taggués, autrement dit descendre dans la topologie mais celle-ci n'est pas encore construite puisque c'est précisément pendant sa construction que l'information est nécessaire.

On notera par ailleurs que le client n'avait pas non plus réalisé qu'il y avait un problème à ce niveau là. En fait nous pensons que nous nous sommes laissés abuser par le fait que la méthode permettant de récupérer les forwarding lists ventilés par VLAN n'était pas standard (c'est une méthode spécifique au constructeur 3Com). Aussi, pour nous, c'est inconsciemment la méthode normalisée (celle conforme aux RFCs) qui était la plus judicieuse...


Amélioration de l'interface

Nous nous sommes inspirés de l'implémentation des méthodes d'affichage de Nagios [20] d'arbres réseau sur plusieurs niveaux, dans le but de rester le plus compatible possible avec les versions futures de ce logiciel afin de profiter des corrections de bugs/améliorations dans leurs algorithmes de placement des machines.

Outre le rajout de menus pour appeler les fonctionnalités, nous avons réglé quelques problèmes d'affichage comme des scintillements dus à une méthode de rafraichissement peu judicieuse (lecture d'un fichier configurant une couleur pour chaque lien). De plus, un réaffichage était réalisé à chaque ajout sur la représentation graphique du réseau, ce qui ralentit l'affichage.


Autres améliorations

Quant à l'algorithme de topologie, nous l'avons amélioré après notre analyse du document [18]; d'autre part nous avons pu voir grâce à cette étude qu'il n'existait pas de solution miracle. Certains cas mal traités dans l'algorithme d'origine ont été mis en évidence par les exemples de cas fournis dans le document. En outre, il propose un algorithme complet; cependant celui-ci est difficile à implémenter et nous avons donc préféré améliorer celui qui existait et qui était assez proche de celui-ci plutôt que de le jeter.

D'autre part, un certain nombre de bugs mineurs comme des fuites mémoires ont été corrigés.

Il existait plusieurs fichiers de configuration pour lesquels le groupe de l'année dernière avait écrit un parser à la main. Celui-ci marchait moyennement; nous avons donc écrit un parser de fichier de configuration avec yacc et lex afin de faciliter le paramétrage de l'application et surtout l'ajout de nouvelles directives de configuration.

Il fonctionne maintenant sur les plateformes suivantes:


previous up next contents index Projet de fin d'année Logiciel
< Ingénierie de la solution < > Bilan >
Christophe GIAUME 2002-05-27