Réalisation d'un système de supervision de réseaux de capteurs sans fil.

Dimension: px
Commencer à balayer dès la page:

Download "Réalisation d'un système de supervision de réseaux de capteurs sans fil."

Transcription

1 Institut Supérieur d'informatique de Modélisation et de leurs Applications Cemagref Clermont-Ferrand Unité Technologies et Systèmes d'information pour les Agrosystèmes Complexe des Cézeaux BP Aubière Cedex Complexe des Cézeaux 24,avenue des Landais BP Aubière Cedex ème stage de 2 Rapport d'ingénieur année Filière Réseaux et Télécommunications Réalisation d'un système de supervision de réseaux de capteurs sans fil. Présenté par : Responsable ISIMA : Christophe Tilmant Responsable entreprise : Aurélien Jacquot Date : 6 avril 2009 Durée du stage : 5 mois

2 Remerciements Je tiens tout d'abord à remercier l'ensemble du personnel du Cemagref pour sa convivialité et l'accueil au sein de l'établissement. Je remercie aussi mes encadrants Aurélien Jacquot et Jean-Pierre Chanet pour avoir permis la réalisation de ce projet et plus particulièrement Aurélien Jacquot pour son soutien et sa disponibilité tout au long de ce projet..

3 Table des figures et illustrations Illustration 1: Plateforme LiveNode...3 Illustration 2: Architecture du système LiveNCM...4 Illustration 3: Schéma simplifié de l'organisation de la MIB...7 Illustration 4: Exemple de déclaration d'un nœud de la MIB en ASN1...9 Illustration 5: Principe de fonctionnement d'un estimateur...10 Illustration 6: Principe du fonctionnement de PHP/HTML...11 Illustration 7: Exemple d'objet au format JSON...12 Illustration 8: Utilisation de Google Maps dans l'ancienne interface...13 Illustration 9: Exemple de traitement de l'interface [GARNIER et SABALSKI 2008]...14 Illustration 10: Interface de géo localisation des LiveNodes [GARNIER et SABALSKI 2008]...15 Illustration 11: Schéma de principe de l'utilisation d'une table dans la MIB...16 Illustration 12: Schéma simplifié de la structure adoptée pour la MIB...17 Illustration 13: Diagramme de classes UML du module row_container...19 Illustration 14: Création d'un nouveau réseau...22 Illustration 15: Notification de nouveau nœud...23 Illustration 16: Exemple de document XML...26 Illustration 17: première version de l'algorithme de sauvegarde...27 Illustration 18: Organisation de l'interface...32 Illustration 19: Panel de l'historique des capteurs...34 Illustration 20: Extrait d'un fichier de tests...36 Illustration 21: Résultat de l'exécution du scénario précédent (voir illustration 20)...36

4 Résumé Dans le cadre de ses projets, le Cemagref travaille à la conception d'un système de réseau de capteurs sans fil. C'est au sein de ce projet qu'est développé le système LiveNCM sur lequel j'ai fait mon stage. Ce système a pour but de superviser à distance les différents éléments des réseaux de capteurs sans fil, de permettre de visualiser et modifier leurs configurations ainsi que d'accéder aux différentes valeurs des capteurs. Dans cette optique, j'ai conçu un sous-agent SNMP dont le but est de centraliser les données des différents éléments de ces réseaux de capteurs sans fil. Ce programme est capable de gérer l'ensemble des requêtes nécessaire à la supervision de ces éléments ainsi qu'à l'accès aux différents paramètres et données du système. En complément à ce système, une interface web a été ajoutée permettant à l'utilisateur d'exploiter les réseaux de capteurs sans fil plus simplement via les requêtes du sous-agent. Mots clefs : SNMP, C, Supervision réseau, technologies web, réseaux sans fil. Abstract As a part of its projects, the Cemagref is working on Wireless Sensor Networks. In this project was developed the LiveNCM system on which I have done my placement. The goal of this system is to provide remote supervision for all items of a Wireless Sensor Network and to allow configurations lookup and modification. It also needs to provide access for all various sensor values. In this way, I have designed an SNMP sub-agent used to centralize data for all items inside of these WSNs. This software is able to manage all requests used for the supervision of theses items and for the access to all system's parameters. As a second part of this project, a web interface was added in order to provide an easier use of Wireless Sensor Network with the sub-agent requests. Key-words : SNMP, C, Network Supervision, web technologies, wireless network

5 Table des matières Remerciements Résumé Abstract I Introduction...1 II Sujet de l'étude...2 II.1 Cadre du projet Le Cemagref Le système LiveNCM...2 II.2 Le but du stage...4 II.3 L'existant...5 III Analyse du problème...6 III.1 Le protocole SNMP...6 MIB...6 Agent...8 Capacités d'extension...8 III.2 Les spécificités de LiveNCM [JACQUOT, et al.2008]...9 III.3 L'interface Les technologies de l'interface...10 PHP/HTML...11 JavaScript et AJAX...11 JSON...12 L'API Google Maps Architecture de l'interface [GARNIER et SABALSKI 2008]...13 IV Étude d'une solution...16 IV.1 Étude du système de contrôle Définition de la MIB Gestion des données de l'agent[net SNMP]...18 Structure de données Communication avec l'agent...20 Manipulation des données...20 Protocole de communication...21 Type de connexions Persistance des données...25 Sauvegarde au format XML...26 Optimisation du code du module sauvegarde...27 IV.2 Conception de l'interface Adaptation au modèle...29 Communication...29 Historique...30 Importation des données Extension de l'interface...31 Gestion des informations...31

6 Filtrage des données...33 Gestion de l'historique...33 IV.3 Protocole de test Tests des modules Test de l'application...37 V Discussion Déroulement du projet Résultats...38 VI Conclusion...40 Glossaire/Lexique Références Bibliographiques Annexes

7 I Introduction Dans le cadre de ses projets, le Cemagref développe en collaboration avec le LIMOS un système de supervision destiné aux réseaux de capteurs sans fil (RCSF) appelé LiveNCM. Ce système est basé sur le protocole SNMP utilisé couramment sur les réseau filaires. Le développement d'un tel outil doit faire face à de nombreuses contraintes. Ces difficultés sont principalement dues à l'adaptation du protocole à un milieu ayant des ressources limitées et subissant des contraintes de communication importantes. C'est dans ce contexte qu'il m a été demandé de réaliser une partie d'un système de supervision, capable d'accéder et de modifier différents paramètres d'un nœud à travers le protocole SNMP. Cette partie va principalement passer par la réalisation d'un programme centralisant les données et les commandes de l'ensemble des RCSFs. En parallèle, j'ai travaillé sur une interface capable de contrôler ce système de supervision à distance. Cette interface se basera sur un système de géo-localisation existant développé par des élevés de l'isima. Ce stage a tout d'abord nécessité l'assimilation des concepts utilisés au sein du système LiveNCM afin de pouvoir repérer les différentes contraintes de ce modèle. Cette phase d'analyse des contraintes doit se prolonger ensuite afin de comprendre les modifications à apporter à l'interface pour atteindre le nouveau cahier des charges. Une fois les spécificités du problème connues, j'ai étudié et conçu les divers modules nécessaires à la réalisation du système de supervision et de l'interface. L'ensemble de ces parties est accompagné de tests du système afin de garantir le meilleur fonctionnement possible du programme. Page 1/40

8 II Sujet de l'étude II.1 Cadre du projet 1 Le Cemagref Le Cemagref est un organisme publique de recherche créé dans les années 60 pour des thématiques orientées vers le machinisme agricole, le génie rural et les eaux et forets. Ces sujets ont peu à peu évoluées vers la gestion des ressources naturelles, l'aménagement du territoire et la gestion des risques environnementaux. On retrouve notamment des thématiques autour de l'eau et des systèmes écologiques. Le Cemagref est composé d'une dizaine de centres répartis à travers toute la France. C'est au sein du groupement de Clermont-Ferrand que j'ai effectué mon stage. Ce groupement est implanté sur le campus des Cézeaux et dispose d'une exploitation agricole à Montoldre (03) utilisée pour les expérimentations. J'ai plus particulièrement travaillé au sein de l'unité «Technologies et Systèmes d'information pour les agrosystèmes de Clermont-Ferrand» (TSCF). Cette unité regroupe des chercheurs de disciplines variées tels que l'automatique, l'électronique, le génie des procédés et l'informatique. Les sujets de recherches au sein de TSCF sont orientés vers la mobilité pour la sécurité et la qualité du travail des machines, les technologies d épandage de matériaux organiques ou minéraux, les technologies pour la perception et la caractérisation du sol ainsi que les systèmes d information et de communication partagés. C'est dans cette dernière thématique que j'ai travaillé au sein de l'équipe COPAIN chargée de traiter les données depuis la collecte des mesures jusqu'au stockage dans les bases de données en passant par le développement de systèmes d'informations. Durant la totalité de mon stage, j'ai plus particulièrement travaillé en collaboration avec Aurélien Jacquot à la mise au point du système nommé LiveNCM («Livenode Non invasive Context aware and Modular management»). 2 Le système LiveNCM L'unité TSCF travaille actuellement en collaboration avec le Laboratoire d 'Informatique de Modélisation et d'optimisation des Systèmes (LIMOS) de Clermont-Ferrand à la conception d'un système d'administration de réseau de Page 2/40

9 capteurs sans fil. Un réseau de capteurs sans fil est composé d'un ensemble de nœuds, répartis sur un même site, sur lesquels sont embarqués des capteurs. Ces nœuds sont reliés entre eux grâce à des protocoles de communication sans fil du type Zigbee, WiFi, ou GSM. Chaque réseau contient une passerelle vers l'extérieur, par laquelle il est possible d'accéder à toutes les valeurs des capteurs et d'avoir ainsi un ensemble de données représentatives du site à un moment donné. Dans le cadre du projet du Cemagref, les nœuds seront des modules LiveNode qui ont été développés par le LIMOS (illustration 1). Afin d'avoir la meilleure autonomie possible, ces Livenodes sont composés des équipements minimums nécessaires à la remonté des informations issues des capteurs. On retrouve principalement un processeur, des modules de communication sans fil ainsi que des interfaces pour les capteurs. Illustration 1: Plateforme LiveNode Lors de l'utilisation de ces plateformes, les nœuds seront généralement éloignés de plusieurs dizaines voir centaines de mètres afin de pouvoir couvrir une zone de mesure importante. Dans le but de valider ce fonctionnement, le système sera testé avec des capteurs d'humidité répartis sur la surface d'un champ. C'est dans le cadre de ce projet que le Cemagref développe un système d'administration permettant de diminuer le trafic réseau et d'augmenter l'autonomie des LiveNodes. Ce système, appelé «LiveNode Non invasive Contextaware, and modular Management» (LiveNCM) est basé sur le protocole SNMP et demande, entre autres, un système de contrôle centralisé pour les réseaux de capteurs sans fil (illustration 2). Le système LiveNCM doit permettre à terme de consulter les données capteurs, de surveiller les équipements (LiveNodes/Capteurs/passerelle) à travers Page 3/40

10 divers indices (Batterie, Puissance d'émission...) mais aussi d'intervenir sur certains paramètres (Fréquence d'acquisition, Canal d'émission ). L'ensemble de ces opérations doit pouvoir être réalisé sans forcément se trouver sur le site du réseau concerné. Interface D'administration à Distance Commandes d'administration Données Capteurs / État du système Système de contrôle Passerelle Passerelle LiveNode LiveNode LiveNode LiveNode Capteur Capteurs LiveNode LiveNode Capteur Capteurs Illustration 2: Architecture du système LiveNCM Le développement de ce projet doit en plus répondre à des contraintes fortes en matière d'utilisation des ressources (Batterie, processeur, mémoire). Ces contraintes sont principalement dues à l'utilisation de matériel embarqué avec des puissances de calcul et des ressources limitées. II.2 Le but du stage C'est au niveau de ce système LiveNCM que s'effectue mon stage. Il m'a tout d'abord été demandé de réaliser la partie du système de supervision chargée de communiquer avec les passerelles et avec l'utilisateur. Cela passe principalement par la conception d'un gestionnaire qui centralisera les données issues des passerelles et transmettra les requêtes d'administration aux différents nœuds des Page 4/40

11 RCSFs. La seconde partie du projet correspond à la réalisation d'une interface de visualisation des données issues du système de supervision. L'interface doit permettre en particulier de récupérer des données sur l'état des nœuds et de pouvoir observer les variations des valeurs des capteurs à travers un système d'historiques. Cet outil doit aussi intégrer les commandes d'administration qui devront permettre en particulier le changement de la configuration des capteurs. L'ensemble des opérations de consultation des données et de modification de la configuration doit aussi pouvoir être réalisé à distance le plus simplement possible. II.3 L'existant Lors de mon arrivé, il existait déjà une ébauche de programme de supervision des RCSFs centralisant les données des différents nœuds. Cependant, ce programme a été réalisé dans le but de tester certains concepts liés au modèle LiveNCM. Le cahier des charges de cette première version était ainsi assez éloigné du but recherché, il n'y avait qu'un seul réseau avec un seul capteur par nœud, ce qui le rendait peu flexible. Néanmoins, cette version servira de base à la réalisation du projet en fournissant une première maquette de conception de la solution finale. Par contre, la refonte du programme pour atteindre le cahier des charges, tant au niveau des données que du système lui même, demanderait plus de temps que sa réécriture totale. Par ailleurs, le Cemagref disposait aussi d'une interface web de géolocalisation des LiveNodes développée lors d'un projet de 3éme année ISIMA [GARNIERet SABALSKI 2008]. Cette interface était destinée à repérer sur une carte les différents LiveNodes ainsi qu'à visualiser une donnée issue d'un capteur d'humidité branché sur le nœud. Ce projet a été conçu avec un cahier des charges proche de notre projet (accès à distance, fonctionnalités communes ) ce qui rend sa réutilisation intéressante. Il convient cependant de noter que dans le cadre de l'ancienne interface, on considère que les capteurs sont tous de même type et qu'un nœud embarque un unique capteur. Page 5/40

12 III Analyse du problème La première tâche à accomplir consiste à analyser l'architecture du système recherché et les différentes technologies à utiliser afin d'en comprendre leurs fonctionnements, leurs contraintes et leurs spécificités. Le système LiveNCM développé au Cemagref et au LIMOS propose une nouvelle solution d'administration à distance des nœuds d'un RCSF en se basant sur le protocole SNMP. III.1 Le protocole SNMP Le protocole SNMP («Simple Network Management Protocol») est un protocole de supervision très couramment utilisé dans les réseaux informatiques filaires. Ce protocole a pour but la surveillance et l'administration à distance des équipements réseaux. La liste des périphériques gérés par SNMP est particulièrement importante et permet l'administration d'équipements tels que des imprimantes, des routeurs ou des ordinateurs de bureau. La première version de SNMP apparue en 1990, pose de nombreux problèmes de sécurité qui ont conduit au développement d'une deuxième version en Malgré les améliorations apportées, cette deuxième version du protocole (nommée V2C) présente encore un certain nombre de lacunes qui ont nécessité la mise au point d'une troisième version, plus sure mais toutefois plus complexe à mettre en place. En dépit des risques, les applications utilisant SNMPv1 et SNMPV2c sont encore populaires, notamment grâce à la présence de nombreux outils existants. Le but de ce projet étant principalement de valider les principes de l'architecture LiveNCM à travers une «maquette», j'ai préféré utiliser SNMPv2c afin de simplifier le travail tout en possédant une application plus sure qu'avec la version un. MIB Chacun des paramètres d'un équipement est stocké dans une instance d'une structure de données arborescente appelée Management Information Base (MIB). Chaque branche de l'arborescence possède un identifiant numérique qui correspond à une catégorie particulière de matériel. Ces branches vont pouvoir se diviser en autant de sous-catégories qu'il peut être nécessaire pour un type d'équipement (par Page 6/40

13 exemple dans le cas d'un ordinateur, on peut trouver des catégories sur la mémoire, la carte réseau, le processeur ). Chacune de ces branches vont posséder à leurs extrémités des «feuilles» qui correspondent à des données décrivant l'équipement appelés ressources SNMP. Chacune de ces ressources est identifiée par un «Object IDentifier» (OID) qui est construit selon la séquence des numéros associés aux branches empruntées (voir illustration 3) Pc (1) Disque Dur (1) Capacité en Go (1) Utilisation en % (2) Carte Réseau (2) Adresse IP (1) Vitesse (2) Activé O/N (3) Imprimante(2) Exemple d' OID : Adresse Ip de la carte Réseau Pc(1).Carte Réseau(2).Adresse IP(1) => OID=1.2.1 Encre(1) Papier(2) Routeur (3) Illustration 3: Schéma simplifié de l'organisation de la MIB L'organisation de la MIB a fait l'objet de plusieurs RFC dans le but de la standardiser. On peut principalement citer les RFC 1066 en 1988 décrivant une première structure de la MIB [McCloghrie et Rose 1988] et la RFC 1213 en 1991 définissant la structure de l'arborescence de la MIB-II encore utilisée actuellement [McCloghrie et Rose 1991]. Les différentes ressources de la MIB seront accessibles via les requêtes suivantes : Get(OID) : retourne la valeur contenue dans l'oid correspondant (utilisable via la commande SNMPGET) Ex: SNMPGET(1.1.2) => 1.1.2:: 10% Page 7/40

14 Set(OID) valeur : met le contenu de l'oid à la valeur choisie (utilisable via la commande SNMPSET) Ex: SNMPGET(1.2.1) => 1.2.1:: SNMPSET(1.2.1, ) => 1.2.1:: SNMPGET(1.2.1) => 1.2.1:: Walk(OID): Affiche les valeurs des données d'une branche de la MIB (utilisable via la commande SNMPWALK) en réalisant plusieurs requêtes Get successives. Ex: SNMPWALK(1.1) => 1.1.1:: 300 GO 1.1.2:: 42% Agent La gestion de cette MIB est confiée à un programme de type démon appelé agent SNMP. A chaque agent sera associé une instance de la MIB qui contiendra les données de l'équipement managé. Cet agent va jouer un rôle central dans le protocole : - lorsqu'un utilisateur recherchera une information avec une requête Get, il s'adressera à l'agent qui retournera l'entrée de la MIB qui correspond à la requête. - en cas de modification de la configuration ou du statut d'un élément, l'agent détectera ce changement et modifiera la MIB afin qu'elle reflète le nouvel état de l'équipement managé. - enfin lorsque l'utilisateur décide de modifier un paramètre, il transmettra sa requête à l'agent qui modifiera la MIB et répercutera le changement sur l'équipement concerné. Capacités d'extension L'un des points forts de SNMP est qu'il est possible d'étendre les types équipements supervisés afin de pouvoir manager n'importe quel équipement possédant une carte réseau. Pour cela, il faut tout d'abord décrire la nouvelle branche de la MIB correspondant au nouveau matériel. Cette description va être faite au moyen d'un fichier utilisant la syntaxe ASN1 (voir exemple 4 ci dessous). Page 8/40

15 Nom de L' OID nodesdescid OBJECT TYPE SYNTAX INTEGER( ) MAX ACCESS read only STATUS current "node unique ID" ::= { nodesdesctableentry 1 } Type de données Accessibilité (lecture seule, lecture écriture... ) Champ Obsolète / champ obligatoire ou facultatif Descriptions / notes sur l' OID Branche mére + position dans cette branche Illustration 4: Exemple de déclaration d'un nœud de la MIB en ASN1 En plus de représenter la structure de la nouvelle branche de la MIB, le fichier indiquera aussi à quelle branche de la MIB-II «standard», on devra la greffer. Cette greffe se fait théoriquement dans la branche «private.enterprise» prévue à cet effet. Enfin, pour que cette extension de la MIB soit gérée correctement, on ajoutera un nouveau programme appelé sous-agent contenant les traitements à réaliser pour cette branche. Lorsque l'agent recevra une requête sur un OID qu'il ne sait pas gérer, il s'adressera au sous agent concerné pour la traiter. Les ressources limitées des RCSFs ne permettant pas d'embarquer un agent SNMP, il sera nécessaire de développer un sous agent adapté et une nouvelle branche de la MIB pour gérer les différents paramètres d'un nœud. III.2 Les spécificités de LiveNCM [JACQUOT, et al.2008] La nature des réseaux de LiveNodes présente un certain nombre de spécificités qui ont fortement influencé le modèle. La contrainte principale vient de l'utilisation des technologies employées sur les nœuds : les ressources disponibles étant limitées (en particulier les batteries), il faut diminuer au maximum les temps de calcul et d'envoi de données. L'utilisation d'un démon (qui fonctionne donc en permanence) sur un équipement implique l'utilisation de mémoire constante et des calculs réguliers. Ce type de programme ne peut donc pas être intégré sur des systèmes embarqués à cause de cette contrainte. Afin de résoudre ce problème, l'agent SNMP doit être déporté hors du LiveNode. Dans le modèle choisi, il n'existera qu'un seul agent gérant l'intégralité des RCSFs. Dans le but de décharger une partie du travail de l'agent, ce dernier s'adressera uniquement à des passerelles qui se chargeront de transmettre les requêtes aux LiveNodes et capteurs correspondants. Toujours afin d'économiser l'utilisation de ressources, les communications Page 9/40

16 seront limitées au strict minimum. Un système d'estimateurs a été mis en place pour n'émettre des données que lorsque celles-ci s'éloignent de la valeur estimée (voir illustration 5). Dans la même optique, les paramètres des éléments ne seront envoyés que lors de leurs initialisation ou suite à un changement. Illustration 5: Principe de fonctionnement d'un estimateur Avec ce système, les données des messages émis sont alors très courtes ce qui permet de profiter de place «libre» dans les trames pour ajouter quelques informations critiques (Niveau de batterie du nœud par exemple), permettant ainsi d'éviter quelques envois. III.3 L'interface Une contrainte importante à prendre en compte lors de la conception de l'interface est la possibilité d'utilisation à distance. L'adaptation de l'ancienne interface, réalisée avec des fonctionnalités proches des objectifs du projet, est particulièrement intéressante. 1 Les technologies de l'interface Ce précédent projet se base sur une interface web créée avec les technologies PHP/HTML, JavaScript et AJAX ainsi que l'api Google-Maps. Elle se présente sous la forme d'un site web hébergé par un serveur apache relié à Page 10/40

17 Internet. Grâce à cela, il est notamment possible d'utiliser l'interface à partir de tout ordinateur ayant accès à ce serveur. Le poste client peut fonctionner sous n'importe quel système d'exploitation et doit uniquement disposer d'un navigateur web «moderne» qui acceptera l'exécution de scripts JavaScript. PHP/HTML Le langage HTML est la base de nombreuses technologies Web. Il est composé de balises qui permettent de décrire l'affichage d'une page. Dans le cas le plus simple, un serveur Web (Apache, IIS, ) hébergera des fichiers HTML qui seront envoyés au navigateur web du client qui interprétera les balises afin de reconstruire la page. En complément à HTML, l'utilisation du langage PHP permet à un serveur de générer du code HTML dynamiquement en réponse à une requête d'un client (voir schéma 6). Ce langage est principalement utilisé pour gérer des formulaires ou interfacer des informations issues d'une base de donnée. Poste Client Poste serveur Internet / Réseau Local Navigateur Web Demande de page Web Serveur Web Transition de la requête Recherche de la page Exécution du script PHP (génération d'un flux HTML) Interprétation du HTML (génération de la page à l'écran) Réponse serveur Envoi du HTML Illustration 6: Principe du fonctionnement de PHP/HTML Le principal problème de ce système est que le navigateur se contente de restituer les pages via un flux HTML sans aucune possibilité de traitements dynamiques supplémentaires. La modification d'une page demande alors un autre flux HTML et nécessite donc l'envoi d'une nouvelle requête au serveur. JavaScript et AJAX C'est pour répondre à ce problème qu'est apparu le langage JavaScript. Le Page 11/40

18 principe de cette technologie est d'ajouter au code HTML, un certain nombre de fonctionnalités qui pourront être interprétées par le navigateur en réponse à certains événements (clic de l'utilisateur, survol d'une zone etc...). De plus pour améliorer l'interactivité des pages avec l'utilisateur, le langage AJAX («Asynchronous JavaScript And Xml») a été développé afin de compléter ce système. Le fonctionnement d'ajax s'articule autour de l'objet JavaScript «HttpRequest» qui permet de définir une requête à envoyer au serveur ainsi que la fonction JavaScript qui sera appelée automatiquement à la réception de la réponse. Il est ainsi possible de recharger une partie de la page web plutôt que la totalité et gagner en interactivité. Cela permet indirectement de limiter la taille et le nombre des messages échangés avec le serveur ainsi que de décharger ce dernier d'une partie du travail. Dans le cas de l'interface existante, le langage JavaScript est utilisé via le framework «prototype» qui permet au programmeur d'avoir accès à un ensemble de classes et de fonctions pour faciliter le développement d'applications. Ce framework permet notamment la création d'un objet «Ajax.Request» permettant de définir simplement une requête AJAX. JSON Afin de simplifier le travail du client et du serveur, ainsi que de gagner en maintenance les données transmises via AJAX sont faites grâce au format JSON («JavaScript Object Notation»). Ce format normalisé sert pour le transfert d'informations entre divers langages et systèmes d'exploitation. Un objet JSON correspond à une suite de champs contenue entre deux accolades (illustration 7). Chaque champ est en fait composé du nom de la variable et de la valeur séparés par un caractère ':'. Il est aussi possible de stocker des données sous forme plus complexe comme par exemple des tableaux. Nom attribut { "IdNode" : "3", Valeur attribut "Name" : "exemple", "Sensors" : [ { "IdSensor" : "3", "value" : "4" }, { "IdSensor" : "9", "value" : "4" }, ], Attribut Tableau } Illustration 7: Exemple d'objet au format JSON Un des principaux intérêts de ce format est qu'il correspond à la même notation qu'un objet en JavaScript. Il est ainsi possible de travailler directement en Page 12/40

19 Javascript avec les données JSON. L'API Google-Maps Cette API a été développée par l'entreprise Google afin de rendre possible l'utilisation de cartes, plans et vues satellites à des échelles variées à l'intérieur d'une page web. Cette bibliothèque de fonctions permet, en plus de l'affichage, d'ajouter diverses informations sur les cartes. Il est par exemple possible de signaler un lieu sous la forme d'un picot et d'y associer une description au moyen d'une bulle d'information (infobulle) comme dans l'illustration suivante(illustation 8). Illustration 8: Utilisation de Google Maps dans l'ancienne interface L'API Google-Maps utilise AJAX et JavaScript afin de pouvoir être intégrée dans la plupart des développements web. 2 Architecture de l'interface [GARNIER et SABALSKI 2008] Les technologies utilisées par l'interface doivent exploiter des données venant de diverses sources. Les informations affichées sont à la base issues des LiveNodes que l'on souhaite contrôler. Afin de les récupérer, le serveur web va entrer en Page 13/40

20 communication avec les différents LiveNodes par l'intermédiaire d'une liaison série. Afin d'avoir le maximum d'interactivité, ces liaisons sont réalisées dans un script PHP appelé par le client via une requête AJAX (Illustration 9). Illustration 9: Exemple de traitement de l'interface [GARNIER et SABALSKI 2008] Cette communication série devra toutefois disparaître dans le nouveau système de contrôle. A la place, on s'adressera au démon SNMP afin de limiter les interlocuteurs. Il faut aussi prévoir que l'agent SNMP n'est pas forcement sur le même serveur que l'interface ce qui peut impliquer des temps de traitements plus longs. Certaines informations sont stockées dans deux tables d'une base de donnée MySQL. On retrouve dans la première, la description des nœuds que l'on souhaite gérer, leur identifiant, leur adresse IP, leur position GPS ainsi que la précision des données GPS. La deuxième table associe l'identifiant du LiveNode avec une valeur capteur et une date de relevé afin de constituer un historique. Ce système de base de données présente l'avantage d'être facilement associé à un serveur web à travers de nombreuses fonctions PHP et d'offrir un stockage persistant. L'organisation des données à l'intérieur de cette base devra cependant être repensée pour intégrer la notion de réseau ainsi que la multiplicité des capteurs sur un LiveNode. Page 14/40

21 L'organisation des pages web de ce projet (Illustration 10) se fait via 3 grandes parties : un menu d'ajout/surpression de nœuds une liste des différents LiveNodes répertoriés dans l'interface et un carte permettant de localiser les nœuds. Il est aussi possible d'accéder à une description d'un nœud dans une infobulle en cliquant sur le picot correspondant sur la carte. Illustration 10: Interface de géo localisation des LiveNodes [GARNIER et SABALSKI 2008] L'organisation des informations sur la page web est assez proche de ce que l'on recherche et ne demandera que peu de changements. On devra cependant transformer la liste des LiveNodes en un menu de sélection permettant d'afficher la liste des réseaux, des capteurs ou des nœuds en fonction des besoins de l'utilisateur. Ces listes permettront ensuite de sélectionner le ou les éléments à afficher. On devra aussi ajouter un panel permettant de visualiser les données associées à l'élément sélectionné dans le menu précédent. Page 15/40

22 IV Étude d'une solution IV.1 Étude du système de contrôle La première tache a été de définir et concevoir la structure de la MIB. 1 Définition de la MIB Comme une version «standard» (un agent par Nœud ou réseau, managé avec une MIB de même structure) n'est pas possible à cause des contraintes de ressources, il nous faut centraliser la MIB dans un seul et même agent. L'utilisation d'un unique démon pour gérer un nombre multiple d'instances d'un même type d'équipement n'est cependant pas prévu dans le protocole. La solution consiste alors à voir l'ensemble des réseaux comme un seul équipement, ce qui nécessitera l'utilisation d'un seul agent. Les réseaux sont alors considérés comme des éléments de notre «super-entité». Ils seront alors inscrits dans la MIB par une entrée dans un index SNMP. Il correspond à une branche de la MIB dans laquelle vont être stockées plusieurs sous-branches de structure identique. Chacune des sous-branches est indexée selon une clef numérique unique (illustration 11). Dans le cas de notre application, cette clef servira d'identifiant SNMP de l'élément. LiveNCM LiveNCM Nombre de réseaux (1) Nombre de réseaux (1) Table Réseaux (2) Index:=Id_Réseau Table Réseaux (2) Index:=Id_Réseau Table Réseaux[1] (1) Id_Réseau (1) Id_Réseau (1) Adresse_IP_Passerelle (2) Adresse_IP_Passerelle (2) Table Réseaux[2] (1) Id_Réseau (1) Adresse_IP_Passerelle (2) Illustration 11: Schéma de principe de l'utilisation d'une table dans la MIB Cette solution n'est cependant pas réutilisable telle quelle pour ajouter des objets LiveNodes et capteurs au sein d'un objet réseau. En effet, il est impossible d'utiliser un index à l'intérieur d'un autre. Ce problème est du à une limitation de la MIB qui Page 16/40

23 n'autorise que des données textes ou numériques au sein d'un index (pas de sousbranches ni d'index). La solution consiste alors à «aplatir» la MIB. Dans ce cas, on va devoir créer un index pour chaque «étage» d'un réseau de capteurs. Ces indexes seront greffés à la base de l'arborescence. En ajoutant un attribut parent dans les index LiveNodes et capteurs, les liens de composition de nos réseaux seront conservés. Afin de gagner en flexibilité et en maintenance il peut aussi être utile de décomposer nos index en sous parties. Chaque «étage» n'aura donc plus une unique table mais plusieurs tables définies par catégorie (Description, État, Communication...). Il sera ensuite possible de rajouter différents types de ressources dans chaque niveau, sans changer la totalité de la numérotation des OIDs, en ajoutant un nouvel index. Pour pouvoir utiliser correctement ce principe, il est cependant nécessaire que chaque instance de données utilise la même clef au sein d'un même niveau. Pour ce projet, cette clef sera l'identifiant SNMP de l'élément. Cette contrainte permet de retrouver toutes les données d'une même instance uniquement à partir de son identifiant. En suivant ces principes, la MIB s'articulera autour de 3 branches (Réseaux, LiveNodes et Capteurs) contenant plusieurs indexes correspondant à leurs sous catégories de données (voir illustration 12). LiveNCM Réseaux De capteurs (1) Nombre de réseaux (1) Table Description Réseaux (2) Index:=Id_Description Réseau Id_Description Réseau (1) LiveNodes (2) Nombre de LiveNodes (1) Table Description LiveNodes (2) Index:=Id_description_LiveNode =IdSNMP Id_LiveNode (1) Id_Réseau_Père(2) Table Communication LiveNodes (3) Index:=Id_Communication_LiveNode =IdSNMP Table Statut LiveNodes (2) Index:=Id_Statut_LiveNode =IdSNMP Les index sont les mêmes pour les sous tables d 'un même objet Capteurs (1) Nombre de Capteurs (1) Table Capteurs (2) Index:=Id_Capteur Id_Capteur (1) Id_LiveNode_Père(2) Illustration 12: Schéma simplifié de la structure adoptée pour la MIB Page 17/40

24 2 Gestion des données de l'agent[net-snmp] Une fois la structure de la MIB définie, il faut étudier le programme qui va se charger de sa gestion. La réalisation de l'extension d'un démon SNMP se base sur une bibliothèque C appelée NET-SNMP. Ce choix s'explique par le fait qu'il s'agisse de l'implémentation la plus complète et la plus utilisée pour ce protocole et qu'elle présente l'avantage d'être utilisable tant sous des systèmes UNIX que Windows. NET-SNMP contient aussi un certain nombre d'outils tel que l'utilitaire MIB2C permettant de générer automatiquement une partie du code du sous-agent à partir du fichier de description de la MIB. Ces fichiers contiennent un certain nombre de «blancs» où le développeur devra ajouter le code spécifique à sa MIB. Le code généré par l'outil MIB2C, ainsi que celui de la première version de l'agent du Cemagref, m'ont permis de saisir la logique de traitement d'une requête au sein de l'agent. Cependant, les spécificités du programme à réaliser (décentralisation, multiplicité des éléments managés, hiérarchisation des données) ont demandées une refonte de certaines parties générées. Structure de données Bien que cette librairie dispose de structures de données avancées, je n'ai pas réussi à trouver un système permettant de recréer facilement de lien hiérarchique entre les tables (Lien Réseau/LiveNode et lien LiveNode/Capteur). Ce lien doit pourtant être facilement récupérable dans certains cas comme la suppression d'un réseau. Cette suppression va détruire l'entrée du réseau mais aussi tous les LiveNodes et Capteurs qu'il contient. Il faut donc être capable de récupérer les structures qui dépendent de l'élément supprimé en vue de leur dés-allocation. J'ai donc pour cela conçu un système de conteneurs «génériques» permettant de retrouver les différents niveaux de composants d'un réseau. Les données de la MIB étant principalement stockées dans des indexes, j'ai utilisé une structure net_snmp_tdata (issue de NET-SNMP) conçue à cet effet. Cette structure correspond à une table stockant un conteneur générique tdata_row pour chaque entrée de l'index. Ces tdata_row sont des conteneurs possédant entre autres une structure contenant les données de l'entrée. Le type de la structure contenue dépend des données contenues dans l'index SNMP. Il va donc falloir créer une structure par index, et chaque structure portera un nom correspondant à celui utilisé pour l'index associé. C'est donc les tdata_row qu'il faut être capable de récupérer pour manipuler les données de la MIB. J'ai pour cela créé des structures row_container Page 18/40

25 «encapsulant» les différents tdata_row d'un même niveau hiérarchique (réseau, LiveNode ou capteur). On complétera le row_container par un lien vers le conteneur père, et une liste vers l'ensemble des fils afin de retrouver les relations «père/fils» entre les éléments de la MIB. Enfin, il faut ajouter un lien vers ces row_container dans chaque structure stockée par les tdata_row. De cette manière, lorsque l'on récupère une des structures de NET_SNMP, on accède au row_container associé via les données qu'elle contient. Il est ensuite possible via le conteneur obtenu de récupérer les autres éléments associés. L'ensemble des structures précédentes sont présentées dans l'illustration ci dessous (illustration 13) Illustration 13: Diagramme de classes UML du module row_container Afin de gagner en possibilités d'extensions, il existe aussi un conteneur fictif nommé TopRow, au dessus de tous les réseaux qui peut permettre l'ajout éventuel d'un niveau supérieur (Notion d'ensemble de réseaux par exemple). Lors de l'implémentation de ce système, j'ai essayé de simplifier le travail d'un éventuel développeur reprenant mon programme. Pour cela, j'ai créé une Page 19/40

26 petite API contenant toutes les fonctions nécessaires à la gestion de mes structures de données inspirées du modèle objet. On déchargera au maximum l'utilisateur de la gestion mémoire en lui fournissant un «constructeur» permettant d'allouer de façon transparente les structures de données et un «destructeur» à appeler lorsque le travail est terminé, libérant ces mêmes ressources. L'accès aux données des conteneurs et des structures «entry» est aussi inspiré du modèle objet avec l'utilisation de «getters»(fonction de lecture) et de «setters»(fonction d'écriture) associées à chaque champ. Ces fonctions permettent notamment d'effectuer un contrôle personnalisé pour chaque accès aux champs. J'ai par la suite gardé ce système pour toutes les autres structures de données afin de maintenir une logique dans mon programme. 3 Communication avec l'agent Manipulation des données Cette partie consiste à identifier quels sont les interrogations possibles au sein de l'agent. On en distingue alors deux types : _ tout d'abord, les commandes utilisateur réalisées au moyen de requêtes Get et Set ensuite la communication entre l'agent et les différentes passerelles. La première partie consiste principalement à recopier les données de la MIB dans une trame pour une requête Get ou bien l'inverse dans le cas d'un Set. Ce code ne présente pas de spécificités par rapport à l'agent et est en grande partie généré par l'utilitaire MIB2C. La seconde partie, par contre doit être réalisée par le développeur car elle dépend directement du matériel à contrôler. Dans notre cas, ces interrogations se feront à travers un réseau ce qui demandera de définir les messages que l'on échangera entre ses différentes entités. Il est possible d'imaginer un système simple dans lequel les passerelles envoient des notifications de mise à jour de la MIB via des requêtes Set. La modification des configurations suite à une requête venant de l'utilisateur se gère de la même manière : La passerelle lit la MIB via une requête Get et envoie une notification à l'élément concerné. Cela simplifierait l'implémentation en évitant de coder une partie spécifique pour ce type de communication, mais demanderait que tous les attributs soient mis en lecture écriture. L'utilisateur aurait donc le pourvoir de modifier certaines informations qui devraient lui être inaccessible en écriture (Typiquement la valeur d'un capteur ou le niveau de batterie). Une autre solution consiste à concevoir un protocole de communication entre l'agent et les passerelles via des sockets TCP ou UDP. Cette solution quoi que plus Page 20/40

27 lourde permet de maintenir une séparation entre les commandes utilisateur et celles venant des réseaux de capteurs. J'ai choisi d'utiliser la seconde solution qui permettra une meilleure sécurité pour les données de la MIB en protégeant certains OID des modifications par l'utilisateur. Protocole de communication Afin de garder une unicité au sein du système, le protocole pour la communication entre l'agent et les passerelles va être le même que celui développé par le Cemagref pour la communication au sein des réseaux. Un certain nombre des requêtes qui sont nécessaires à la communication agent/passerelle est déjà défini dans ce protocole car elles circulent aussi au sein des réseaux de capteurs. Pour les interrogations qui n'existent pas, le travail consiste à définir la séquence de messages et les numéros de commande qui y sont associés. Dans les requêtes de mise à jour et de notification d'un changement dans le réseau, ce message est le plus souvent une unique trame définissant la ressource concernée et contenant la nouvelle valeur. Il reste ensuite à définir les messages associés à l'ajout et à la suppression d'éléments. L'ajout d'un nouveau réseau est fait par l'utilisateur qui va indiquer à l'agent, la passerelle associée au réseau à travers une adresse IP et un port réseau. La requête d'ajout d'une passerelle demande cependant de mettre à jour deux attributs (adresse IP et port) ce qui va demander deux requêtes successives car les commandes Set ne supportent qu'un seul argument. Afin de laisser la possibilité à plusieurs utilisateurs de faire un ajout simultanément, il faut être capable de reconstituer les couples IP/port même si les requêtes arrivent dans le désordre exemple : utilisateur_1 setport utilisateur_2 setport utilisateur_2 setip utilisateur_1 setip Il existe deux solutions sures et faciles à mettre en œuvre pour ce problème: Il est envisageable de regrouper les requêtes setip et setport en une seule au moyen d'une chaine de caractères formatée regroupant les deux arguments. Avec cette solution, l'utilisation d'une seule requête est possible mais peu «élégante» car il sera nécessaire de garder les OIDs capables de récupérer le port et l'adresse séparément pour autoriser une consultation par l'utilisateur d'un de ces paramètres. La deuxième solution consiste à donner un numéro à chaque couple de commandes. Il faut pour cela trouver une méthode permettant à l'utilisateur de réserver un identifiant unique avant d'effectuer sa Page 21/40

28 transaction. Cela peut être facilement réalisé en ajoutant un OID renvoyant un identifiant SNMP libre pour le réseau. J'ai choisi d'utiliser la deuxième solution malgré le fait qu'elle soit plus complexe car elle répond mieux au modèle prévu par SNMP (Une requête = un paramètre). Pour améliorer ce système, on demandera à l'utilisateur de confirmer sa réservation. Tant que cela n'a pas été fait l'identifiant retourné par l'oid de réservation sera le même. Cela permet d'éviter qu'une requête Get ou Walk ne réserve définitivement un OID pour rien. La séquence des messages précédemment cités est présentée par le diagramme suivant (illustration 14). Illustration 14: Création d'un nouveau réseau La confirmation va se faire par une requête Set sur l'oid de réservation. Cet OID ne correspondant pas à des données, il est judicieux de le séparer des autres dans la MIB. J'ai donc pour cela ajouter une branche commande qui contiendra les OIDs ne correspondant pas réellement à des ressources mais plutôt utilisés pour maintenir la MIB. Afin de simplifier le travail de l'utilisateur, les LiveNodes et les Capteurs seront détectés automatiquement par les passerelles (voir illustration 15). Cette détection sera notifiée à l'agent par un message de la passerelle qui déclenchera l'allocation Page 22/40

29 des structures de données adaptées. La passerelle recevra ensuite un message en retour indiquant quel est l'identifiant du nouvel élément. Une fois l'élément créé, celui ci peut envoyer une trame pour annoncer sa configuration initiale. Illustration 15: Notification de nouveau nœud Dans le cas d'un nouveau LiveNode, une adresse IP sera automatiquement attribuée en fonction de son identifiant et de celui de son réseau. L'unicité de l'adresse au sein des réseaux de capteurs est garantie grâce à un formatage spécial : On va tout d'abord prendre la plus grande plage d'adresse IP utilisable en réseau local ( classe A => de à soit 232 adresses) Afin que l'agent puisse envoyer les messages pour un LiveNode vers le bon réseau de capteurs, on placera l'identifiant du réseau (de 1 à 255) dans la partie haute de l'adresse. Exemple: plage d'adresse du réseau N 20 => de à Le reste de l'adresse sera constituée par l'identifiant du nœud (de 1 à 65534) Exemple : LiveNode N 200 dans le réseau 241 => La suppression d'éléments du réseau, par contre, ne peut pas être automatique. En effet, il est impossible de distinguer un LiveNode qui n'a plus de batterie, un réseau perdant temporairement sa connectivité ou un élément qui a été supprimé réellement (dans tous ces cas, on va uniquement détecter une absence Page 23/40

30 de communication). Il faut donc laisser la responsabilité de la suppression d'un élément à l'utilisateur. La suppression d'un élément reviendra à effectuer un SET sur un OID prévu à cet effet avec en paramètre l'identifiant de l'élément à libérer. L'agent devra ensuite notifier la commande à la passerelle qui effectuera les traitements qui s'imposent. Les OIDs de suppression seront ensuite insérés dans la branche commande de la MIB précédemment crée. Type de connexions Après la définition de ce protocole, il nous faut choisir le type de sockets à utiliser pour la communication. Avant de choisir le type de communication, il faut remarquer qu'il existe deux types de trafic réseau entre les passerelles et l'agent. des commandes émises par l'agent dont le message contient au plus un unique paramètre (nouvelle valeur de l'attribut à modifier). Elles seront suivies d'un accusé de réception venant de la passerelle concernée. des données de capteurs et des configurations modifiées en provenance des passerelles et à destination de l'agent. Les trames seront la aussi courtes. La perte de trames non détectée peut avoir des conséquences importantes notamment à cause de l'estimateur. On peut, par exemple, avoir un envoi suite à une variation importante des données capteurs exigeant de recalculer la courbe d'estimation. Si ce paquet se perd, l'agent continuera à tort d'utiliser les mêmes estimations et faussera toutes les demandes de valeurs suivantes. Les traitements à effectuer lors de la réception de données sont totalement différents, ce qui impose logiquement de créer deux fonctions distinctes. Dans le cas de notre agent, ces fonctions seront déclenchées par l'arrivée de données sur une socket. Il devient alors nécessaire de séparer ces deux types de trafic sur deux sockets différentes. Pour la réalisation d'une application utilisant le réseau pour transmettre des données via un réseau local ou internet, il existe principalement deux protocoles utilisables au niveau des sockets. Il est possible d'utiliser une transmission synchrone via le protocole «Transmission Control Protocol» (TCP) ou asynchrone via «User Datagram Protocol» (UDP). L'utilisation de TCP permet d'avoir un transport fiable car il intègre un accusé de réception, et les trames arrivent dans l'ordre et sans duplication. Son utilisation se fait en mode connecté ce qui va demander une socket par connexion. L'exploitation de cette solution demande donc de gérer les connexions avec les Page 24/40

31 différentes passerelles (soit en ouvrant les connexions au besoin et en les refermant ensuite, soit avec un tableau de correspondance passerelle/socket) De son coté, le protocole UDP permet une transmission non connectée : le transport est non fiable, c'est à dire, pas d'accusé de réception, et les paquets peuvent arriver dans le désordre ou être dupliqués. Il devient alors plus difficile de reconstituer un message fragmenté en plusieurs trames. Son utilisation est plus courante pour un «flot» de données où la perte de paquets est moins déterminante que la vitesse de transmission. Ce protocole permet de fixer le destinataire à l'envoi et non à la connexion. On a donc la possibilité de n'utiliser qu'une socket pour l'ensemble des passerelles et d'effectuer des messages multicasts et broadcast (envoi à un groupe ou à tous les postes d'un réseau local). J'ai choisi l'utilisation de l'udp pour le trafic de commandes issues de l'agent. En effet, les principaux avantages de TCP ne sont pas déterminants dans ce cas: l'arrivée de trames dans le désordre est surtout problématique dans le cas de messages fragmentés ce qui n'est pas le cas ici. Les commandes envoyées par l'agent aux passerelles consistant uniquement à des modifications de paramètres ou des suppressions d'éléments, un deuxième appel de la commande suite à une duplication de paquets n'aura aucun impact sur le résultat. Seul le système d'accusés de réception est un avantage. Les commandes issues de l'agent sont cependant envoyées de façon séquentielles ce qui rend l'ajout de cette fonctionnalité facile dans notre cas (attente de réception d'un message en retour ou nouvel essai dans le cas contraire). De plus, l'utilisation d'une socket UDP unique est beaucoup plus facile à gérer et l'utilisation du multicast pour les commandes peut ouvrir des perspectives intéressantes (envoi d'une commande «mise en veille» à l'ensemble des réseaux par exemple) Le choix du protocole dans le cas des données issues des passerelles sera différent. La duplication de trames ou la perte de paquets de la passerelle vers l'agent peut avoir des conséquences plus graves. On pourrait par exemple avoir une perte d'une mesure issue d'un estimateur : l'agent considérerait que les valeurs suivent toujours ses estimations alors que la courbe peut avoir pris une évolution complètement différente. De plus, l'agent n'est pas en permanence à l'écoute des passerelle, ce qui rend la réalisation d'un accusé de réception plus complexe à réaliser. L'utilisation de TCP semble donc plus adaptée dans ce cas. 4 Persistance des données La partie suivante de l'étude concerne la persistance des données de l'agent. Les agents SNMP sont conçus pour stocker leurs structures de données dans leurs mémoire (libérée en cas d'arrêt) plutôt que sur le disque. Dans un agent «classique», cela ne pose pas de problèmes particuliers, car en cas de reprise après un arrêt, l'agent rechargera les données dans l'élément qu'il administre. Page 25/40

32 Dans notre agent, ce rechargement est difficilement possible, car ce dernier aura «oublié» l'architecture des réseaux (IP des passerelles, LiveNodes composant un réseau etc...). Il sera donc incapable de savoir à qui s'adresser pour récupérer ces informations. Afin d'assurer la conservation des données après un arrêt (volontaire ou non) de l'agent, il faut mettre en place une méthode de sauvegarde pour les données sur le disque. Stocker les structures de données de l'agent sur disque plutôt que dans la mémoire est possible mais cependant lourd à gérer avec NET-SNMP. Une solution plus simple consiste à créer des sauvegardes persistantes lors de l'arrêt. Il est alors possible de charger la dernière sauvegarde créée au démarrage de l'agent. Cette solution permet aussi de pouvoir revenir à une date ultérieure suite par exemple à une erreur de manipulation. Afin d'avoir une possibilité de reprise après un arrêt inopiné (coupure de courant, défaillance du programme) il est aussi envisageable de sauvegarder régulièrement l'état de la MIB grâce à une routine périodique de sauvegarde. Sauvegarde au format XML J'ai choisi d'utiliser des fichiers XML classiques car ce type de stockage est très répandu avec de nombreuses bibliothèques permettant cette gestion. De plus, il sera possible pour l'utilisateur d'exploiter ces fichiers avec un autre outil. Ce standard a été défini afin de créer un système de stockage portable, facilement utilisable pour de nombreuses applications [W3C 2004]. <mon_element> <donnée_texte_de_mon_element> Ceci est un test </donnee_texte_de_mon_element> <liste_contenu> <donnee_du_contenu> 42 </donnee_du_contenu> <donnee_du_contenu> 43 </donnee_du_contenu> </liste_contenu> <mon_élément> Illustration 16: Exemple de document XML Ce langage définit une classe d'objet de données appelée document XML. Ils sont construits autour d'un modèle arborescent organisé à travers un ensemble de balises et se manipulent à travers un programme nommé processeur XML. Chaque jeu de deux balises (début <...> et fin </...>) délimite un élément XML qui peut être des données brutes (texte, numérique, image ) ou bien d'autres éléments délimités par deux autres balises (voir illustration 16). Le standard défini aussi l'utilisation d'une grammaire, permettant la description du format d'un type de document, appelée «Document Type Page 26/40

33 Declaration» (DTD). Il est ainsi possible de tester si un document est valide, c'est à dire s'il possède la structure attendue pour ce type de document. J'ai cherché parmi les bibliothèques de gestion XML celles utilisables en langage C afin de garder une homogénéité dans mon programme. J'ai choisi d'utiliser la libxml2 qui est la plus utilisée dans ce langage et est inspirée du modèle objet. La manipulation de données à travers cette bibliothèque se fait grâce à un objet XmlDocument. L'écriture d'un document se fait facilement à l'aide de trois fonctions permettant d'ouvrir et fermer des balises à la position courante ou d'ajouter des données dans la dernière balise ouverte. On obtient une première version de la fonction de sauvegarde semblable à celle présenté par l'illustration 17. creerdocumentxml ouvrirbalise MIB pour tout réseau ouvrirbalise réseau ouvrirbalise id_réseau ecriredonnéenumerique id_réseau fermerbalise id_réseau ouvrirbalise nom_réseau ecriredonnéetexte nom_réseau fermerbalise adresse_réseau... ouvrirbalise noeudréseau pour tout noeud du réseau fin pour fermerbalise réseau fin pour fermerbalise enregistrer Document Illustration 17: première version de l'algorithme de sauvegarde Optimisation du code du module sauvegarde Les versions des d'algorithmes de sauvegarde et de chargement présentées ne sont cependant pas optimales car elles utilisent de façon redondante des blocs très semblables composés de trois fonctions (ouverture_balise, traitement, fermeture_balise). Avec ce système, on aboutit à des fonctions très longues et Page 27/40

34 répétitives qu'il est possible de raccourcir. De plus, ces fonctions sont peu flexibles car un changement de la structure des données demande de modifier une certaine quantité de code associée. Néanmoins, il est possible de créer à la place de ces blocs une unique fonction qui réalise ces trois opérations. Ces fonctions seraient définies comme suit : écrire_donnée_mib_dans_xml_(document, balise, donnée) écrire_donnée_xml_dans_mib(document, Ces fonctions devront se décliner en deux versions, car la gestion d'attributs textes demande un paramètre de plus, pour la longueur chaine de caractères, que les attributs numériques. L'utilisation d'une programmation «orientée objet» pour les données de la MIB m'a permis d'imaginer une autre modification. On peut noter que ces fonctions utilisent des données sans effectuer de contrôles spécifiques sur leur validité (Bornes, format d'une adresse IP ). Ces traitements sont par contre réalisés dans les fonctions getters/setters implémentées pour la MIB. Les getters (et les setters) sur des données d'un même type ont des prototypes identiques. Il devient alors facile de transformer les fonctions précédentes afin qu'elles prennent comme paramètres la fonction d'accès à élément (à travers un pointeur de fonction) qui sera utilisée pour écrire les données avec contrôles ou lire la ressource. Afin d'améliorer encore le module, j'ai créé un système permettant de ne pas changer le code des fonctions de sauvegarde lors d'une modification de la structure de la MIB. L'idée de ce système est d'avoir une structure de description de la MIB. Chaque OID va être décrit par son getter, son setter son type et le nom de la balise XML associée. La sauvegarde (ou le chargement) reviendra à parcourir la structure et d'appeler le getter (réciproquement le setter) avec les arguments correspondant en fonction du type d'objet. Le documents XML et la MIB ayant tout les deux une structure arborescente, le parcours de la structure peut se faire de la même manière. La fonction de parcours doit donc être capable de parcourir n'importe quelle arborescence pour satisfaire tous les cas d'organisation possibles dans le cadre du projet LiveNCM. Grâce à ces améliorations, le travail d'un programmeur modifiant la structure des sauvegardes XML revient à écrire cette description dans un fichier prévu à cet effet (voir annexes). Cette description se fait simplement grâce à 5 fonctions : XML_NEW_TABLE_DESC => début de la description d'une table XML_TABLE_ADD_TABLE => ajout d'une sous table dans la table en cours de description XML_TABLE_ADD_SEQ => ajout d'une sous table index dans la table en cours de description Page 28/40

35 XML_TABLE_ADD_INTEGER => ajout d'un attribut de type numérique XML_TABLE_ADD_STRING => ajout d'un attribut chaine de caractères IV.2 -Conception de l'interface La conception de l'interface se déroulera en trois parties principales : _ Il va tout d'abord être nécessaire de convertir l'ancien projet afin qu'il corresponde au nouveau modèle. _ La deuxième partie consistera en l'ajout des fonctionnalités permettant de gérer les configurations des nœuds. _ Enfin, on s'occupera de la gestion des valeurs capteurs et de la présentation de l'historique. 1 Adaptation au modèle Communication Contrairement à l'ancienne version du projet qui utilisait une liaison série vers les LiveNodes, l'interface doit récupérer les données en s'adressant à l'agent via SNMP. L'utilisation des fonctions SNMP est gérée par PHP grâce à une extension du langage. Une fois cette extension installée, il suffit de remplacer la communication série par des fonctions SNMP. La principale différence entre ces deux méthodes est qu'une requête SNMP est associée à une ressource alors que la communication série renvoie une trame contenant un ensemble d'informations associées à un nœud. Le nombre de requêtes pour un affichage va donc être plus important et peut causer un plus long temps de traitement. Ce temps peut être particulièrement important lorsque l'on demande l'affichage de tous les nœuds sur la carte par exemple. Afin de remédier à cela on cherchera à mémoriser les informations qui n'ont pas de raisons de changer et qui sont utilisées régulièrement. Ces informations sont de deux 2 types : l'architecture des réseaux (liste des nœuds d'un réseau et liste des capteurs connectés sur un nœud) et les positions GPS qui seront utilisées par Google-Maps. Pour stocker ces données, on réutilisera l'ancienne base de données du projet grâce à trois nouvelles tables réseau, nœuds et capteurs. En plus de répondre au problème, ce système permet aussi de simplifier certaines requêtes nécessitant de filtrer les données. En effet, il est beaucoup plus simple et plus rapide de faire un filtre avec une requête sur la base de données plutôt que de récupérer l'ensemble des données SNMP et de ne garder que celles qui correspondent. Page 29/40

36 Les différents accès aux données seront ensuite réalisés selon le modèle suivant : Le client appellera un script JavaScript pour préparer une requête AJAX vers le serveur contenant le nom de la fonction à exécuter avec une liste de paramètres préalablement formée. Ensuite, du coté serveur, on récupérera les identifiants des ressources à interroger, soit à partir des paramètres du script, soit à travers une requête à la base de donnée. On va ensuite boucler sur chacun de ces identifiants et récupérer les données en réalisant une commande SNMP par ressources concernées. Une fois l'ensemble des ressources récupérées, on construit une trame JSON selon un format spécifique au script. Ce JSON sera retourné au client et exploité par la fonction JavaScript prévue pour la réception. Historique L'historique de l'ancienne interface reposait sur la base de données. Elle supposait cependant qu'il n'existait qu'un capteur par nœud sans faire de distinction de type ni d'unité. L'historique doit forcement se faire hors de l'agent car les démons SNMP sont conçus pour être l'image d'un équipement à un instant donné sans avoir de «mémoire». Il est ainsi impossible d'accéder à d'anciennes valeurs par le biais de l'agent. Cet historique va donc rester dans la base de donnée qui devra être réorganisée. Pour cela, la table historique contiendra l'identifiant du capteur, une date de prise, sa valeur ainsi que son type, son facteur et son unité de mesure. Importation des données Dans le système existant, les LiveNodes qui étaient gérés dans l'interface, étaient ajoutés et supprimés manuellement puis mis à jour dans la base. Il est possible de reproduire ce comportement au niveau de l'ajout de réseaux et de la suppression d'éléments, mais pas au niveau des nœuds et des capteurs. En effet, ces derniers sont détectés automatiquement par l'agent qui doit pouvoir fonctionner indépendamment de l'interface et ne peut donc ajouter les identifiants dans la base de données. Il est donc nécessaire de trouver un moyen de mettre à jour régulièrement la structure des réseaux dans la base. Pour cela,j'ai conçu un script PHP qui permet de détecter les différences entre les données de la MIB et celle de la base. La première partie du script recherchera les identifiants SNMP des éléments Page 30/40

37 des réseaux de capteurs à l'intérieur de la MIB au moyen de la commande SNMPWALK appelée via l'extension de PHP. Ensuite, on récupère l'ensemble des identifiants réseaux, LiveNodes et capteurs et on les compare avec ceux de SNMP. Tous les nouveaux éléments détectés feront l'objet d'une fonction récupérant les données nécessaires à leur insertion dans la base de données. Ce script devra ensuite être appelé périodiquement afin de s'assurer que l'utilisateur puisse consulter des données à jour. Pour cela, on peut utiliser un démon présent sur la majorité des systèmes UNIX : l'ordonnanceur de taches périodiques nommé «Cron». Ce démon a pour but de gérer les taches répétitives en lançant des scripts à des horaires précis. Il suffit donc d'indiquer le script PHP à l'ordonnanceur pour qu'il exécute la synchronisation à la fréquence définie par l'utilisateur dans son fichier de configuration. 2 Extension de l'interface A la suite de ces modifications, pour transposer l'interface dans la nouvelle architecture, il est maintenant nécessaire d'ajouter les fonctionnalités propres au nouveau projet. Gestion des informations La partie la plus importante consiste à ajouter la possibilité de consulter et modifier les configurations des éléments du réseau. La première tache consiste tout d'abord à identifier les différentes informations utilisables issues de la MIB. Parmi ces informations toutes ne possèdent pas la même pertinence. On va donc classer ces informations en 3 types : tout d'abord, les données essentielles (Identifiant, niveaux de batterie, valeur capteur...) qui vont être affichées en priorité. Ces données vont notamment se retrouver dans le menu de sélection afin de donner un rapide aperçu de l'ensemble des éléments. Les données de fonctionnement (nombre de LiveNodes d'un réseau, puissance du signal reçu, type de capteur ) qui donnent des informations sur l'équipement sélectionné mais qui ne peuvent pas être modifiées par l'utilisateur. Ces données seront affichés dans un menu décrivant les valeurs de l'élément sélectionné. Enfin, on retrouvera les données de configuration. Il s'agit d'informations sur lesquels l'utilisateur a la possibilité d'agir. Ces données feront l'objet d'une sous partie dans le menu informations. Cette sous partie pourra être passée en mode lecture ou bien modification grâce à un bouton. Page 31/40

38 Chacune de ces types d'informations fera l'objet d'un traitement différent via une requête AJAX. Jusqu'à présent les données sur un élément du réseau étaient affichées au sein d'une infobulle sur la carte. Les informations à gérer dans la nouvelle version sont beaucoup plus nombreuses et ne pourront être traitées de cette façon. Il a donc été nécessaire d'ajouter un nouveau panel à l'interface. Ce panel sera rempli à chaque choix d'un élément à visualiser dans le menu sélection. Il sera divisé en 3 parties (illustration 18) consultation des informations gestion des configurations affichage de la liste des éléments fils (liste des capteurs du nœud / liste des LiveNodes d'un Réseau). Menu d'ajout des Réseaux de capteurs Menu Informations (données en consultation uniquement) Numéro de la commande 0_4_4_initContainer_ 11_5_5_getChildVide_ 12_0_0_getFirstChildVide_ 13_0_0_removeFirstChildVide_ 9_5_5_removeChildVide_ 10_5_5_ajoutUnique_ Paramètres de la commande Description de la ligne Menu configuration (données modifiables par l'utilisateur) Liste des éléments (informations essentielles) Illustration 18: Organisation de l'interface Page 32/40

39 Filtrage des données Malgré les améliorations pour limiter le trafic et augmenter la vitesse de l'interface, un grand nombre de réseaux visualisés peut demander un temps de traitement très important. De plus, il est rarement utile de visualiser l'intégralité des données en même temps. Afin de remédier à cela, on va donc chercher à limiter l'affichage aux données demandées par l'utilisateur. Ce filtrage peut intervenir à deux principaux niveaux : tout d'abord, il peut être utile de limiter les données à certains critères (Pas de réseaux vides, filtrage sur un ou plusieurs attributs...) l'utilisateur peut aussi choisir manuellement de ne pas afficher certains éléments. Pour le premier type de requêtes, on prévoit pour chaque script PHP qui sera appelé via AJAX des paramètres facultatifs permettant de gérer les filtres. Ces filtres seront pris en compte par les script PHP lors de la phase de sélection des identifiants SNMP à récupérer. Ces différents filtres seront configurables par l'utilisateur via un menu prévu à cet effet. Dans le second cas, il s'agit d'ajouter dans la liste des éléments sélectionnés, une possibilité pour cacher un élément que l'on a défini par une case à cocher symbolisant ce choix. Les éléments cachés resteront uniquement visibles au niveau de la liste de sélection mais n'apparaitront plus au niveau du reste de l'interface. La liste des éléments cachés est mémorisée dans trois tableaux JavaScript (un par niveau) afin de pouvoir s'en souvenir lors d'un nouvel affichage (après un changement de filtre par exemple). Pour compléter, on cachera aussi les fils d'un élément caché. Pour cela, on a ajouté trois autres tableaux JavaScript contenant les identifiants affichés actuellement dans chaque niveau. Ces tableaux seront reremplis après chaque changement de filtre au moyen du flux de données envoyé par le serveur. Ces tableaux seront ensuite passés à tous les scripts PHP sur des niveaux inférieurs. Les scripts PHP limiteront leurs recherches aux identifiants qui sont associés à des descendants des éléments inscrits dans le tableau. Gestion de l'historique Jusqu'à présent, les données des capteurs étaient mémorisées dans une base de données mais n'étaient jamais réellement exploitées par l'interface. Afin de présenter l'évolution des données d'un capteur, j'ai choisi d'intégrer un graphique à la description de chaque capteur. Pour cela, j'ai cherché une librairie permettant de réaliser des graphes, utilisable avec les technologies web. Mon choix s'est alors porté sur une librairie basée sur le framework prototype et sur AJAX nommée FLOTR. Cette API est particulièrement complète (zoom, courbes multiples, gestion d'événements ) et présente une syntaxe facilement utilisable [SOLUTOIRE]. Le choix de cette librairie est aussi du au fait qu'elle n'utilise que des technologies qui Page 33/40

40 étaient déjà utilisées dans l'interface, et n'allonge pas la liste des bibliothèques dont on dépend. Au moyen des événements de cette API, un panel (illustration 19) a été conçu pour permettre à l'utilisateur de spécifier une période de recherche d'historiques, de gérer différents niveaux de zoom et de se déplacer facilement dans le temps. Ce panel a ensuite été intégré au niveau du menu d'information pour les objets capteurs. Illustration 19: Panel de l'historique des capteurs L'historique hérité de l'ancienne interface présente un autre point perfectible : la base de données n'est remplie que lorsqu'un utilisateur déclenche une capture. Ce système a pour conséquences d'avoir généralement peu de valeurs pour un même capteur sur une longue durée. L'automatisation des mesures va permettre d'avoir une meilleure vision de l'évolution des données capteurs à travers le temps. Comme dans le cas de la synchronisation base / MIB, on s'appuiera sur le démon Cron pour alimenter la base de données à l'aide du même script que celui qu'exécute l'utilisateur lorsqu'il décide de faire une capture manuelle. IV.3 Protocole de test Tout programme nécessite un certain degré de tests afin de garantir une bonne fiabilité. Cela est d'autant plus important dans le cas de l'agent SNMP créé. En effet, comme tous les démons et les serveurs réseau, le programme doit fonctionner en permanence. Un arrêt du programme s'accompagne alors d'un arrêt du service qui peut laisser passer un certain nombre d'informations importantes. Page 34/40

Administration Réseau

Administration Réseau M1 Réseaux Informatique et Applications Administration Réseau Date: 02/04/07 Auteurs: Alexis Demeaulte, Gaël Cuenot Professeurs: Patrick Guterl Table des matières 1Introduction...3 2HP OPENVIEW...3 3Les

Plus en détail

et Groupe Eyrolles, 2006, ISBN : 2-212-11747-7

et Groupe Eyrolles, 2006, ISBN : 2-212-11747-7 Tsoft et Groupe Eyrolles, 2006, ISBN : 2-212-11747-7 OEM Console Java OEM Console HTTP OEM Database Control Oracle Net Manager 6 Module 6 : Oracle Enterprise Manager Objectifs Contenu A la fin de ce module,

Plus en détail

Version 1.0 Janvier 2011. Xerox Phaser 3635MFP Plate-forme EIP

Version 1.0 Janvier 2011. Xerox Phaser 3635MFP Plate-forme EIP Version 1.0 Janvier 2011 Xerox Phaser 3635MFP 2011 Xerox Corporation. XEROX et XEROX and Design sont des marques commerciales de Xerox Corporation aux États-Unis et/ou dans d'autres pays. Des modifications

Plus en détail

Introduction aux Systèmes Distribués. Introduction générale

Introduction aux Systèmes Distribués. Introduction générale Introduction aux Systèmes Distribués Licence Informatique 3 ème année Introduction générale Eric Cariou Université de Pau et des Pays de l'adour Département Informatique Eric.Cariou@univ-pau.fr 1 Plan

Plus en détail

Programmation Avancée pour le Web

Programmation Avancée pour le Web L3 Informatique Option : ISIL Programmation Avancée pour le Web RAMDANI Med U Bouira 1 Contenu du module Introduction aux applications Web Rappels sur les sites Web Conception d une application Web Notion

Plus en détail

Protocoles DHCP et DNS

Protocoles DHCP et DNS Protocoles DHCP et DNS DHCP (Dynamic Host Configuration Protocol) est un protocole qui permet à un serveur DHCP (Unix, Windows, AS400...) d'affecter des adresses IP temporaires (et d'autres paramètres)

Plus en détail

SNMP. Table des matières. notes SNMP

SNMP. Table des matières. notes SNMP notes SNMP Table des matières 1 Description...2 2 Implémentations...2 2.1 Unix (Paquetage ucd-snmp / net-snmp)... 2 2.2 Windows...3 3 OpenNMS... 3 3.1 Principes... 3 3.2 Configuration:...4 3.3 Manipulations...4

Plus en détail

Active Directory Sommaire :

Active Directory Sommaire : Active Directory Sommaire : Définition Ce qu'il permet A quoi sert-il? Principe de fonctionnement Structure Hiérarchie Schéma Qu'est ce qu'un service d'annuaire? Qu'elle est son intérêt? L'installation

Plus en détail

Création et gestion des stratégies

Création et gestion des stratégies Réseaux avec Windows Serveur Création et gestion des stratégies LIARD Fabrice, Lycée Gustave Eiffel 16, chemin de la Renardière 93220 Gagny Version 2010.1 réseaux avec windows Serveur Profils et Stratégies

Plus en détail

Le client/serveur repose sur une communication d égal à égal entre les applications.

Le client/serveur repose sur une communication d égal à égal entre les applications. Table des matières LES PRINCIPES DE BASE... 1 Présentation distribuée-revamping...2 Présentation distante...3 Traitements distribués...3 données distantes-rd...4 données distribuées-rda distribué...4 L'ARCHITECTURE

Plus en détail

Fonctionnement du serveur Z39.50

Fonctionnement du serveur Z39.50 Fonctionnement du serveur Z39.50 Table des matières 1 Configuration du serveur...2 1.1 Comportement du serveur...2 1.2 Configuration de la traduction z39.50 -> base de données...2 1.3 Configuration du

Plus en détail

Documentation de l'application de gestion de courrier évolutive (G.E.D.) pour la Mairie de Voreppe

Documentation de l'application de gestion de courrier évolutive (G.E.D.) pour la Mairie de Voreppe Documentation de l'application de gestion de courrier évolutive (G.E.D.) pour la Mairie de Voreppe Tony Galmiche le 28 février 2011 (modifiée alb) Sommaire 1 - Accès au portail de l'application GED...3

Plus en détail

Documentation de CMS-gen

Documentation de CMS-gen Table des matières GÉNÉRALITÉ... 1 LA ZONE D'ADMINISTRATION... 2 LOGIN SUR LA ZONE D ADMINISTRATION... 2 EDITION DU CONTENU EN LIGNE... 3 LE MODE EDITION... 3 PUBLICATION... 3 SUPPRIMER DES MODIFICATIONS...

Plus en détail

Programmabilité du réseau avec l'infrastructure axée sur les applications (ACI) de Cisco

Programmabilité du réseau avec l'infrastructure axée sur les applications (ACI) de Cisco Livre blanc Programmabilité du réseau avec l'infrastructure axée sur les applications (ACI) de Cisco Présentation Ce document examine la prise en charge de la programmabilité sur l'infrastructure axée

Plus en détail

MEMOIRE DE STAGE. RESUME Etude et adaptation ou développement d un module Wordpress évolué de fédération, gestion et publication ciblée d actualités.

MEMOIRE DE STAGE. RESUME Etude et adaptation ou développement d un module Wordpress évolué de fédération, gestion et publication ciblée d actualités. MEMOIRE DE STAGE RESUME Etude et adaptation ou développement d un module Wordpress évolué de fédération, gestion et publication ciblée d actualités. Simon Richard Maître de stage : M. Alexandre Delpeuch

Plus en détail

Rapport d'architecture

Rapport d'architecture Romain Alexandre Cécile Camillieri Rapport d'architecture 1 / 12 Table des matières I) Description du projet p. 3 1) Canaux de communication p. 3 2) Diagrammes de cas d'utilisation p. 3 II) Gestion des

Plus en détail

GESTION CENTRALISÉE DELL POWERVAULT DL 2000 OPTIMISÉ PAR SYMANTEC

GESTION CENTRALISÉE DELL POWERVAULT DL 2000 OPTIMISÉ PAR SYMANTEC GESTION CENTRALISÉE DELL POWERVAULT DL 2000 OPTIMISÉ PAR SYMANTEC NOTE DE SYNTHESE La solution Dell PowerVault DL2000 optimisée par Symantec Backup Exec est la seule à proposer un système intégré de sauvegarde

Plus en détail

Présentation du projet:

Présentation du projet: : Le but du projet est de réaliser le fonctionnement d'un jeu d échec valide. Plus spécifiquement, il consiste à implémenter l'organisation générale du jeu, et le suivi des règles du mouvement des pièces.

Plus en détail

SYSTEME DE GESTION DES ENERGIES EWTS EMBEDDED WIRELESS TELEMETRY SYSTEM

SYSTEME DE GESTION DES ENERGIES EWTS EMBEDDED WIRELESS TELEMETRY SYSTEM SYSTEME DE GESTION DES ENERGIES EWTS EMBEDDED WIRELESS TELEMETRY SYSTEM Copyright TECH 2012 Technext - 8, avenue Saint Jean - 06400 CANNES Société - TECHNEXT France - Tel : (+ 33) 6 09 87 62 92 - Fax :

Plus en détail

DataTraveler 410. Manuel d'utilisation de SecureTraveler

DataTraveler 410. Manuel d'utilisation de SecureTraveler Manuel d'utilisation de SecureTraveler SecureTraveler est l'utilitaire de configuration DataTraveler permettant aux utilisateurs en entreprise et aux utilisateurs privés d'établir des zones publiques et

Plus en détail

Projet 2. Gestion des services enseignants CENTRE D ENSEIGNEMENT ET DE RECHERCHE EN INFORMATIQUE. G r o u p e :

Projet 2. Gestion des services enseignants CENTRE D ENSEIGNEMENT ET DE RECHERCHE EN INFORMATIQUE. G r o u p e : CENTRE D ENSEIGNEMENT ET DE RECHERCHE EN INFORMATIQUE Projet 2 Gestion des services enseignants G r o u p e : B E L G H I T Y a s m i n e S A N C H E Z - D U B R O N T Y u r i f e r M O N T A Z E R S i

Plus en détail

Réf. 2402 Implémentation et gestion de Microsoft Exchange Server 2003

Réf. 2402 Implémentation et gestion de Microsoft Exchange Server 2003 Public Ce cours est destiné aux informaticiens qui gèrent une messagerie électronique dans un environnement comprenant entre 250 et 5000 utilisateurs, réparti sur de nombreux sites, utilisant divers protocoles

Plus en détail

Terminologie de l'enquête

Terminologie de l'enquête Terminologie de l'enquête 5 octobre 2015 Terme ou abréviation Accès à distance Accès sécurisé, de l'extérieur du parlement, au réseau parlementaire (ou Intranet) Accès ouvert Accès public, immédiat et

Plus en détail

CHAPITRE 1. Introduction aux web services. 1.1 Définition. Contenu du chapitre : Env. De dev. Langage Visual Studio Java EE Qt Creator C#

CHAPITRE 1. Introduction aux web services. 1.1 Définition. Contenu du chapitre : Env. De dev. Langage Visual Studio Java EE Qt Creator C# CHAPITRE 1 Introduction aux web services Contenu du chapitre : Env. De dev. Langage Visual Studio Java EE Qt Creator C# NetBeans JavaScript Eclipse Objective C Xcode PHP HTML Objectifs du chapitre : Ce

Plus en détail

Chap.9: SNMP: Simple Network Management Protocol

Chap.9: SNMP: Simple Network Management Protocol Chap.9: SNMP: Simple Network Management Protocol 1. Présentation 2. L administration de réseau 3. Les fonctionnalités du protocole 4. Les messages SNMP 5. Utilisation de SNMP 1. Présentation En 1988, le

Plus en détail

Le meilleur de l'open source dans votre cyber cafe

Le meilleur de l'open source dans votre cyber cafe Le meilleur de l'open source dans votre cyber cafe Sommaire PRESENTATION...1 Fonctionnalités...2 Les comptes...3 Le système d'extensions...4 Les apparences...5 UTILISATION...6 Maelys Admin...6 Le panneau

Plus en détail

Notions de base sur SNMP

Notions de base sur SNMP Notions de base sur SNMP Quelques rappels sur SNMP SNMP est un protocole permettant a un Manager de dialoguer avec différents agents sur le réseau. L objectif de ces mécanismes est de pouvoir superviser

Plus en détail

Annuaire : Active Directory

Annuaire : Active Directory Annuaire : Active Directory Un annuaire est une structure hiérarchique qui stocke des informations sur les objets du réseau. Un service d'annuaire, tel qu'active Directory, fournit des méthodes de stockage

Plus en détail

Master d'informatique. Réseaux. Supervision réseaux

Master d'informatique. Réseaux. Supervision réseaux Master d'informatique Réseaux Supervision réseaux Bureau S3-354 mailto:jean.saquet@info.unicaen.fr http://www.info.unicaen.fr/~jean/radis Supervision des réseaux Système dépendants des réseaux physiques

Plus en détail

Établir et maintenir la connectivité - Guide de l'utilisateur Utilisateur final - Conseils pour les offres de services à distance

Établir et maintenir la connectivité - Guide de l'utilisateur Utilisateur final - Conseils pour les offres de services à distance Établir et maintenir la connectivité - Guide de l'utilisateur Utilisateur final - Conseils pour les offres de services à distance Table des matières Introduction... 1 Perte de communication après une

Plus en détail

LANGAGUE JAVA. Public Développeurs souhaitant étendre leur panel de langages de programmation

LANGAGUE JAVA. Public Développeurs souhaitant étendre leur panel de langages de programmation ING 01 LANGAGUE JAVA Durée : 21 heures 1090 HT / jour Dates : à définir en 2012 Concevoir et développer des programmes en langage Java Comprendre le fonctionnement de la machine virtuelle S approprier

Plus en détail

Gestion du service des enseignements Analyse détaillée. Gestion du service des enseignements. Ce document est la propriété exclusive du groupe GSE

Gestion du service des enseignements Analyse détaillée. Gestion du service des enseignements. Ce document est la propriété exclusive du groupe GSE 1 sur 54 Projet Émetteur du Document Groupe GSE Destinataire du Document J.L. Massat Titre Nom Du Fichier O_Analyse_Detaillee_v2.1.pdf Version v2.1 Historique Des Versions Version Date Création Date Validation

Plus en détail

Le langage PHP permet donc de construire des sites web dynamiques, contrairement au langage HTML, qui donnera toujours la même page web.

Le langage PHP permet donc de construire des sites web dynamiques, contrairement au langage HTML, qui donnera toujours la même page web. Document 1 : client et serveur Les ordinateurs sur lesquels sont stockés les sites web sont appelés des serveurs. Ce sont des machines qui sont dédiées à cet effet : elles sont souvent sans écran et sans

Plus en détail

Supervision de réseau

Supervision de réseau Supervision de réseau Master Informatique première année Olivier Flauzac olivier.flauzac@univ-reims.fr Olivier Flauzac (URCA) Supervision de réseau olivier.flauzac@univ-reims.fr 1 / 58 Plan 1 Supervision

Plus en détail

Installation d'un serveur DHCP sous Windows 2000 Serveur

Installation d'un serveur DHCP sous Windows 2000 Serveur Installation d'un serveur DHCP sous Windows 2000 Serveur Un serveur DHCP permet d'assigner des adresses IP à des ordinateurs clients du réseau. Grâce à un protocole DHCP (Dynamic Host Configuration Protocol),

Plus en détail

Module 15 : Mise en œuvre de Microsoft SNMP (Simple Network Management Protocol)

Module 15 : Mise en œuvre de Microsoft SNMP (Simple Network Management Protocol) Module 15 : Mise en œuvre de Microsoft SNMP (Simple Network Management Protocol) 0RGXOH#48#=#0LVH#HQ#±XYUH#GH#0LFURVRIW#6103#+6LPSOH#1HWZRUN#0DQDJHPHQW#3URWRFRO,# # 66: # 3UpVHQWDWLRQ#JpQpUDOH 'RQQHU#XQ#DSHUoX#GHV

Plus en détail

WEBMESTRE : CONCEPTION DE SITES ET ADMINISTRATION DE SERVEURS WEB

WEBMESTRE : CONCEPTION DE SITES ET ADMINISTRATION DE SERVEURS WEB WEBMESTRE : CONCEPTION DE SITES ET ADMINISTRATION DE SERVEURS WEB Installation et administration d un serveur web Module 25793 TP A5 (1/2 valeur) Chapitre 1 Fonctionnalités d un serveur web, le protocole

Plus en détail

Guide d'installation et de démarrage du Driver X-WAY sur TCP/IP

Guide d'installation et de démarrage du Driver X-WAY sur TCP/IP Guide d'installation et de démarrage du Driver X-WAY sur TCP/IP Sommaire Chapitre Page 1 Mise en oeuvre 1/1 1.1 Généralités 1/1 1.1-1 Architecture documentaire 1/1 1.1-2 Compatibilités 1/1 1.2 Installation

Plus en détail

Le farming dans DokuWiki, intérêt et mise en œuvre

Le farming dans DokuWiki, intérêt et mise en œuvre Le farming dans DokuWiki, intérêt et mise en œuvre Etienne MELEARD Comité Réseau des Universités Université de Rennes 1, Campus Beaulieu 35042 Rennes Cedex Résumé DokuWiki est une plateforme de Wiki souple

Plus en détail

HTML5 et JavaScript Développez des applications pour le Windows Store

HTML5 et JavaScript Développez des applications pour le Windows Store Avant-propos 1. Pourquoi ce livre? 15 2. À qui s adresse cet ouvrage? 16 3. Structure de l ouvrage 17 4. Remerciements 17 Le système d exploitation Windows 1. Introduction 19 2. Le système Microsoft Windows

Plus en détail

LANDPARK NETWORK IP LANDPARK NETWORK IP VOUS PERMET D'INVENTORIER FACILEMENT VOS POSTES EN RÉSEAU

LANDPARK NETWORK IP LANDPARK NETWORK IP VOUS PERMET D'INVENTORIER FACILEMENT VOS POSTES EN RÉSEAU LANDPARK NETWORK IP Avril 2014 LANDPARK NETWORK IP VOUS PERMET D'INVENTORIER FACILEMENT VOS POSTES EN RÉSEAU Landpark NetworkIP est composé de trois modules : Un module Serveur, que l'on installe sur n'importe

Plus en détail

Un serveur FTP chez soi Tutoriel pour Filezilla FTP server

Un serveur FTP chez soi Tutoriel pour Filezilla FTP server Space-OperaRécitsLogicielsCréationsBlogForum Un serveur FTP chez soi Tutoriel pour Filezilla FTP server DynDNS : Pourquoi et comment? Téléchargement et installation de Filezilla Server Configuration réseau

Plus en détail

Date de diffusion : Rédigé par : Version : Mars 2008 APEM 1.4. Sig-Artisanat : Guide de l'utilisateur 2 / 24

Date de diffusion : Rédigé par : Version : Mars 2008 APEM 1.4. Sig-Artisanat : Guide de l'utilisateur 2 / 24 Guide Utilisateur Titre du projet : Sig-Artisanat Type de document : Guide utilisateur Cadre : Constat : Les Chambres de Métiers doivent avoir une vision prospective de l'artisanat sur leur territoire.

Plus en détail

La Programmation Web avec PHP

La Programmation Web avec PHP Nouvelle page 1 La Programmation Web avec PHP Qu'est-ce que php? Menu Qu'est ce que php? Les scripts PHP Installation de PHP Configuration d'un serveur IIS Mohamed SIDIR PHP est un langage de script HTML,

Plus en détail

Gestion d une flotte de robots Configuration et ordre de missions

Gestion d une flotte de robots Configuration et ordre de missions Document Rapport Version Version 1.0 Date 25/03/2008 Auteur Ahmed RADOUA M1 SET Gestion d une flotte de robots Configuration et ordre de missions INSSET UPJV 1 ième année de MASTER Spécialité : (Année

Plus en détail

Support de cours de la formation izi-media

Support de cours de la formation izi-media Support de cours de la formation izi-media Préambule Ce support de cours s'adresse aux participants du module de formation «izi-media». Il n'a pas pour but de se substituer à la formation présentielle,

Plus en détail

Infrastructure - Gestion des réseaux. Document FAQ. Infrastructure - Gestion des réseaux. Page: 1 / 12 Dernière mise à jour: 16/04/14 15:48

Infrastructure - Gestion des réseaux. Document FAQ. Infrastructure - Gestion des réseaux. Page: 1 / 12 Dernière mise à jour: 16/04/14 15:48 Document FAQ Infrastructure - Gestion des réseaux EXP Page: 1 / 12 Table des matières Détails de la fonctionnalité... 3 I.Généralités... 3 II.Réseaux... 3 III.Édition d'un réseau... 4 IV.Visualisation

Plus en détail

Présentation du modèle OSI(Open Systems Interconnection)

Présentation du modèle OSI(Open Systems Interconnection) Présentation du modèle OSI(Open Systems Interconnection) Les couches hautes: Responsables du traitement de l'information relative à la gestion des échanges entre systèmes informatiques. Couches basses:

Plus en détail

Guide rapide GFI LANguard

Guide rapide GFI LANguard Guide rapide GFI LANguard INTRODUCTION Bienvenue dans GFI LANguard : Votre solution tout en un pour la gestion de correctifs, l'analyse de vulnérabilités et l'audit réseau. GFI LANguard (ou "LANguard")

Plus en détail

Langage HTML (2 partie) lt La Salle Avignon BTS IRIS

Langage HTML (2 partie) <HyperText Markup Language> <tv>lt La Salle Avignon BTS IRIS</tv> Langage HTML (2 partie) «Je n'ai fait que prendre le principe d - hypertexte et le relier au principe du TCP et du DNS et alors boum! ce fut le World Wide Web!» Tim Berners-Lee

Plus en détail

Le site engarde-service.com pour publier des résultats de compétitions Service proposé par la société ANPV-log

Le site engarde-service.com pour publier des résultats de compétitions Service proposé par la société ANPV-log Le site engarde-service.com pour publier des résultats de compétitions Service proposé par la société ANPV-log 1. introduction 2. Création d'un compte sur engarde-service.com 2.1. Inscription 2.2 Gestion

Plus en détail

Serveur de Licences Acronis. Guide Utilisateur

Serveur de Licences Acronis. Guide Utilisateur Serveur de Licences Acronis Guide Utilisateur TABLE DES MATIÈRES 1. INTRODUCTION... 3 1.1 Présentation... 3 1.2 Politique de Licence... 3 2. SYSTEMES D'EXPLOITATION COMPATIBLES... 4 3. INSTALLATION DU

Plus en détail

La sécurité. Chapitre 6. 1. Introduction. 2. La sécurité des accès

La sécurité. Chapitre 6. 1. Introduction. 2. La sécurité des accès 259 Chapitre 6 La sécurité 1. Introduction La sécurité La sécurité des données est un enjeu capital. Une base de données peut être amenée à stocker des données très sensibles, confidentielles. L'implémentation

Plus en détail

Logiciel d application

Logiciel d application Logiciel d application Routeur IP/KNX Caractéristiques électriques/mécaniques: voir notice du produit Référence produit Désignation produit Réf. logiciel d'application Produit filaire Produit radio TH210

Plus en détail

Chapitre 1 : Introduction aux Systèmes de Gestion de Bases de Données (Eléments de base)

Chapitre 1 : Introduction aux Systèmes de Gestion de Bases de Données (Eléments de base) Chapitre 1 : Introduction aux Systèmes de Gestion de Bases de Données (Eléments de base) 1. Généralités sur l'information et sur sa Représentation 1.1 Informations et données : a. Au sen de la vie : C

Plus en détail

Manuel utilisateur. des. listes de diffusion. Sympa. l'université Lille 3

Manuel utilisateur. des. listes de diffusion. Sympa. l'université Lille 3 Manuel utilisateur des listes de diffusion Sympa à l'université Lille 3 1 Table des matières Table des matières...2 I. Introduction...3 II. Principe général de fonctionnement de «Sympa»...3 1. Les principaux

Plus en détail

Vue d'ensemble de Document Portal

Vue d'ensemble de Document Portal Pour afficher ou télécharger cette publication ou d'autres publications Lexmark Document Solutions, cliquez ici. Vue d'ensemble de Document Portal Lexmark Document Portal est une solution logicielle qui

Plus en détail

Architectures web/bases de données

Architectures web/bases de données Architectures web/bases de données I - Page web simple : HTML statique Le code HTML est le langage de base pour concevoir des pages destinées à être publiées sur le réseau Internet ou intranet. Ce n'est

Plus en détail

HelpAndManual_unregistered_evaluation_copy GESTIONNAIRE D'ALARMES CENTRALISE OPTIM'ALARM. Manuel d'utilisation

HelpAndManual_unregistered_evaluation_copy GESTIONNAIRE D'ALARMES CENTRALISE OPTIM'ALARM. Manuel d'utilisation HelpAndManual_unregistered_evaluation_copy GESTIONNAIRE D'ALARMES CENTRALISE OPTIM'ALARM Manuel d'utilisation OPTIMALOG 2008 Table des matières I Table des matières Part I Gestionnaire d'alarmes Optim'Alarm

Plus en détail

Gestion du design (DesignManager)

Gestion du design (DesignManager) 1 sur 7 15/10/2014 14:06 Administration de CMS Made Simple - evolution biologique - Gestionnaire de Modules Bienvenu(e) : archeo Vous avez 1 notification en cours Gestionnaire de Modules Déposer les fichiers

Plus en détail

Manuel d'utilisation d'apimail V3

Manuel d'utilisation d'apimail V3 Manuel d'utilisation d'apimail V3 I Préambule Page 3 II Présentation Page 4 III Mise en route Configuration Page 5 Messagerie Serveur smtp Serveur pop Compte pop Mot de passe Adresse mail Laisser les messages

Plus en détail

SOMMAIRE PRESENTATION... 3 SITE SNMP... 4 SITE TRAP SNMP... 7 HISTORIQUE DES VERSIONS LOGICIELLES... 11

SOMMAIRE PRESENTATION... 3 SITE SNMP... 4 SITE TRAP SNMP... 7 HISTORIQUE DES VERSIONS LOGICIELLES... 11 FRANÇAIS MANUEL D UTILISATION Ressources SNMP Home II - 138.Avenue Léon Bérenger - 06706 Saint-Laurent du Var Cedex : 04 93 19 37 37 - : 04 93 07 60 40 - : 04 93 19 37 30 Site : www.wit.fr SOMMAIRE PRESENTATION...

Plus en détail

SUPPORT DE COURS WINDOWS VISTA

SUPPORT DE COURS WINDOWS VISTA SOMMAIRE I.... LA GESTION DE L'ORDINATEUR... 2 A.... LES UNÎTES LOGIQUES... 2 1 DISQUES DURS... 2 2 SUPPORTS AMOVIBLES... 3 3 PROPRIÉTÉS DU SUPPORT... 3 B... LE CONTENU DE L'ORDINATEUR... 4 1 DOSSIERS...

Plus en détail

Démarrer avec la suite collaborative SCOUT

Démarrer avec la suite collaborative SCOUT Démarrer avec la suite collaborative SCOUT SCOUT - Service COllaboratif de l'université de Toulouse 07 Octobre 2015 Version : V1.0 UFTMIP SCOUT - Service COllaboratif de l'université de Toulouse Version

Plus en détail

Publication d'application

Publication d'application Publication d'application Vue d'ensemble JetClouding supporte 3 types de publication d'application: Microsoft Remote Desktop: L'utilisateur verra le Bureau à distance Windows dans la session. Le contrôle

Plus en détail

JAVA PROGRAMMATION. Programme. 1. Java, HTML et World Wide Web

JAVA PROGRAMMATION. Programme. 1. Java, HTML et World Wide Web PROGRAMMATION PUBLIC Professionnels informatiques qui souhaitent développer des applications et «applets» Java DUREE 4 jours 28 heures OBJECTIF Créer divers «applets» à intégrer dans un site Web dynamique,

Plus en détail

II Importation et retrait automatiques de

II Importation et retrait automatiques de II Importation et retrait automatiques de postes de travail Les services d'importation et de retrait automatiques de postes de travail de Novell ZENworks for Desktops (ZfD) permettent de gérer facilement

Plus en détail

Guillaume LHOMEL Laboratoire Supinfo des Technologies Microsoft Très Bien. Tous les articles de cet auteur 40007 47/227

Guillaume LHOMEL Laboratoire Supinfo des Technologies Microsoft Très Bien. Tous les articles de cet auteur 40007 47/227 Auteur Serveur Windows 2000 dans un Réseau Macintosh Accueil > Articles > Réseau Guillaume LHOMEL Laboratoire Supinfo des Technologies Microsoft Très Bien Tous les articles de cet auteur 40007 47/227 Présentation

Plus en détail

PAIE V20 Module SAGE DS (Déclaration Sociale) FAQ - Module Déclarations Sociales et N4DS

PAIE V20 Module SAGE DS (Déclaration Sociale) FAQ - Module Déclarations Sociales et N4DS PAIE V20 Module SAGE DS (Déclaration Sociale) FAQ - Module Déclarations Sociales et N4DS FAQ Sage Paie Patchs Les patchs Sage paie et Sage DS sont actuellement disponibles. Il convient de les installer

Plus en détail

Prise en mains du dispositif ENR - 1/12 Sites de gestion du serveur, Intranet

Prise en mains du dispositif ENR - 1/12 Sites de gestion du serveur, Intranet Système clients serveur Kwartz 1 - Site de gestion du serveur : Kwartz~control L accès au Kwartz~control est réservé aux personnes possédant quelques connaissances en informatique. Le simple fait d entrer

Plus en détail

Guide d'utilisation du Serveur USB

Guide d'utilisation du Serveur USB Guide d'utilisation du Serveur USB Copyright 20-1 - Informations de copyright Copyright 2010. Tous droits réservés. Avis de non responsabilité Incorporated ne peut être tenu responsable des erreurs techniques

Plus en détail

But de cette présentation

But de cette présentation Réseaux poste à poste ou égal à égal (peer to peer) sous Windows But de cette présentation Vous permettre de configurer un petit réseau domestique (ou de tpe), sans serveur dédié, sous Windows (c est prévu

Plus en détail

KWISATZ_TUTO_module_magento novembre 2012 KWISATZ MODULE MAGENTO

KWISATZ_TUTO_module_magento novembre 2012 KWISATZ MODULE MAGENTO _TUTO_module_magento Table des matières -1) - :...2-1.1) Introduction :...2-1.2) Description :...3-1.2.1) Schéma :...3-1.3) Mise en place :...4-1.3.1) MAGENTO :...4-1.3.1.1) Les Web Services :...4-1.3.1.2)

Plus en détail

LAB-Multimedia CMS. Guide d'auto-formation. Copyright by LAB-Multimedia 1/13

LAB-Multimedia CMS. Guide d'auto-formation. Copyright by LAB-Multimedia 1/13 Guide d'auto-formation Copyright by LAB-Multimedia 1/13 Auteurs Ont participé à la réalisation de cet ouvrage: Luc A. Bardet Editeur LAB-Multimedia Rue du Casino CH-1063 Chapelle-sur-Moudon (Switzerland)

Plus en détail

CONDUITE & GESTION DE PROJET

CONDUITE & GESTION DE PROJET LES THEMES DU PROGRAMME PEDAGOGIQUE CONDUITE & GESTION DE PROJET Techniques de gestion de projets Connaître le rôle d un chef de projet dans la conduite de projet. Les méthodes, les techniques et les outils

Plus en détail

Intégration Insight Mgr 7 Guide Utilisateur

Intégration Insight Mgr 7 Guide Utilisateur Intégration Insight Mgr 7 Guide Utilisateur Intégration HP Insight Manager 7 - Guide Utilisateur - 34 033 731 XU / AG Page 1/13 Table des matières 1 Introduction...3 2 Procédure d'installation et de configuration...3

Plus en détail

Sage CRM. 7.2 Guide de Portail Client

Sage CRM. 7.2 Guide de Portail Client Sage CRM 7.2 Guide de Portail Client Copyright 2013 Sage Technologies Limited, éditeur de ce produit. Tous droits réservés. Il est interdit de copier, photocopier, reproduire, traduire, copier sur microfilm,

Plus en détail

Google Chrome. La barre de favoris: Une petit barre (Ctrl+B) qui fait tout la largeur du navigateur juste en dessous de la barre de recherche.

Google Chrome. La barre de favoris: Une petit barre (Ctrl+B) qui fait tout la largeur du navigateur juste en dessous de la barre de recherche. Google Chrome Résumé rapide: Lien de téléchargement: http://www.google.fr/chrome La barre de favoris: Une petit barre (Ctrl+B) qui fait tout la largeur du navigateur juste en dessous de la barre de recherche.

Plus en détail

Windows 2008 server -Introduction-

Windows 2008 server -Introduction- Windows 2008 server -Introduction- Rappel sur les systèmes d exploitation Un système d exploitation (Operating System) est un ensemble de programmes responsables de la liaison entre les ressources matérielles

Plus en détail

La Gestion Électronique des Documents avec Open ERP

La Gestion Électronique des Documents avec Open ERP La Gestion Électronique des Documents avec Open ERP La Gestion Électronique des Documents avec Open ERP V e r s i o n d u d o c u m e n t V1.0 Introduction...4 I Installer la GED dans Open ERP...5 1 Les

Plus en détail

Objectifs. Maîtriser. Pratiquer

Objectifs. Maîtriser. Pratiquer 1 Bases de Données Objectifs Maîtriser les concepts d un SGBD relationnel Les modèles de représentations de données Les modèles de représentations de données La conception d une base de données Pratiquer

Plus en détail

Windows 8 Installation et configuration

Windows 8 Installation et configuration Editions ENI Windows 8 Installation et configuration Collection Ressources Informatiques Extrait 112 Windows 8 Installation et configuration Pour terminer l'application de l'image, nous devons configurer

Plus en détail

Fonctionnalités de développement

Fonctionnalités de développement 163 Chapitre 5 Fonctionnalités de développement 1. Optimisation des applications ASP.NET Fonctionnalités de développement 1.1 Présentation de ASP.NET ASP.NET est un ensemble de technologies créé par Microsoft

Plus en détail

THEGREENBOW FIREWALL DISTRIBUE TGB::BOB! Pro. Spécifications techniques

THEGREENBOW FIREWALL DISTRIBUE TGB::BOB! Pro. Spécifications techniques THEGREENBOW FIREWALL DISTRIBUE TGB::! Pro Spécifications techniques SISTECH SA THEGREENBOW 28 rue de Caumartin 75009 Paris Tel.: 01.43.12.39.37 Fax.:01.43.12.55.44 E-mail: info@thegreenbow.fr Web: www.thegreenbow.fr

Plus en détail

White Paper - Livre Blanc

White Paper - Livre Blanc White Paper - Livre Blanc Développement d applications de supervision des systèmes d information Avec LoriotPro Vous disposez d un environnement informatique hétérogène et vous souhaitez à partir d une

Plus en détail

Plugin Payment-OnLine

Plugin Payment-OnLine Plugin Payment-OnLine Le plugin "Payment-Online" est un plugin technique dont l'objectif est de faciliter l'utilisation du paiement en ligne dans des applications Lutèce. Il se compose d'une librairie

Plus en détail

Architecture N-Tier. Ces données peuvent être saisies interactivement via l interface ou lues depuis un disque. Application

Architecture N-Tier. Ces données peuvent être saisies interactivement via l interface ou lues depuis un disque. Application Architecture Multi-Tier Traditionnellement une application informatique est un programme exécutable sur une machine qui représente la logique de traitement des données manipulées par l application. Ces

Plus en détail

SeeTec 5. Glossaire - 1 -

SeeTec 5. Glossaire - 1 - SeeTec 5 Glossaire - 1 - Table des matières A...3 B...3 C...3 D...4 E...4 F...4 G...4 H...5 I...5 J...5 K...5 L...5 M...5 N...6 O...6 P...6 Q...7 R...7 S...7 T...7 U...7 V...8 W...8 X...8 Y...8 Z...8-2

Plus en détail

PRODIGE V3. Manuel utilisateurs. Consultation des métadonnées

PRODIGE V3. Manuel utilisateurs. Consultation des métadonnées PRODIGE V3 Manuel utilisateurs Consultation des métadonnées Pour plus d'information sur le dispositif : à remplir par chaque site éventuellement 2 PRODIGE V3 : Consultation des métadonnées SOMMAIRE 1.

Plus en détail

NOTICE DE EOBD-FACILE

NOTICE DE EOBD-FACILE NOTICE DE EOBD-FACILE POUR ios (iphone/ipad) EOBD-Facile iphone/ipad 1 Outils OBD Facile copyright 1. Paramétrer le réseau WiFi pour l'interface ELM327 Depuis le menu Réglages puis WiFi, faites la configuration

Plus en détail

Plan. Supervision de réseau. Supervision. Plan. Généralités. Master Informatique première année. Olivier Flauzac

Plan. Supervision de réseau. Supervision. Plan. Généralités. Master Informatique première année. Olivier Flauzac Plan Supervision de réseau Master Informatique première année Olivier Flauzac olivier.flauzac@univ-reims.fr Olivier Flauzac (URCA) Supervision de réseau olivier.flauzac@univ-reims.fr 1 / 39 Olivier Flauzac

Plus en détail

Exemple de projet. «Gestion de contacts»

Exemple de projet. «Gestion de contacts» Université Paul Valéry Montpellier 3 Antenne universitaire de Béziers L3 AES parcours MISASHS ECUE «Logiciels spécialisés» Exemple de projet «Gestion de contacts» G. Richomme Table des matières 1. Introduction...

Plus en détail

MEDIAplus_page de garde_v67_mise en page 1 09/12/2010 09:23 Page 2. MEDIAplus elearning. version 6.7

MEDIAplus_page de garde_v67_mise en page 1 09/12/2010 09:23 Page 2. MEDIAplus elearning. version 6.7 MEDIAplus_page de garde_v67_mise en page 1 09/12/2010 09:23 Page 2 MEDIAplus elearning version 6.7 L'interface d administration MEDIAplus Sommaire 1. L'interface d administration MEDIAplus... 5 2. Principes

Plus en détail

Projet Viticulture - TP 4 : Projet H2O de traitement des eaux en viticulture BTS Services informatiques aux organisations

Projet Viticulture - TP 4 : Projet H2O de traitement des eaux en viticulture BTS Services informatiques aux organisations Projet Viticulture TP 4 : projet H2O Description du thème Partie 1 : bases de données locales SQLite Partie 2 : projet H2O stockage local Partie 3 : bases de données distantes Partie 4 : projet H2O synchronisation

Plus en détail

La traçabilité et/ou le contrôle de produits ou de personnes par technologie RFID

La traçabilité et/ou le contrôle de produits ou de personnes par technologie RFID La traçabilité et/ou le contrôle de produits ou de personnes par technologie RFID Conditions Projet Durée : 28 h Moyens Poste informatique sous Windows Lecteur RFID UM 005 Logiciels FRAMER, PROCESSING

Plus en détail

Serveur(s) / Serveur d'applications : Linux Debian

Serveur(s) / Serveur d'applications : Linux Debian (s) / d'applications : Linux Debian On appelle généralement un serveur la machine qui permet l'organisation et la gestion du parc informatique de l'entreprise. Le choix du serveur est important, c'est

Plus en détail

PC Check & Tuning 2010 Optimisez et accélérez rapidement et simplement les performances de votre PC!

PC Check & Tuning 2010 Optimisez et accélérez rapidement et simplement les performances de votre PC! PC Check & Tuning 2010 Optimisez et accélérez rapidement et simplement les performances de votre PC! MAGIX PC Check & Tuning 2010 est la solution logicielle complète pour l'analyse, la maintenance et l'accélération

Plus en détail

Fiche pratique. Les outils systèmes. Maintenance, défragmenter, planifier, sauvegarder

Fiche pratique. Les outils systèmes. Maintenance, défragmenter, planifier, sauvegarder 1 Fiche pratique Les outils systèmes Maintenance, défragmenter, planifier, sauvegarder Les outils système Proposés dans Windows Vista vous permettent de défragmenter, nettoyer, sauvegarder, restaurer...

Plus en détail

WINDOWS SERVER 2003 ADMINISTRATION A DISTANCE

WINDOWS SERVER 2003 ADMINISTRATION A DISTANCE 1. Introduction WINDOWS SERVER 2003 ADMINISTRATION A DISTANCE En règle générale, les administrateurs ne travaillent pas en salle serveurs. Et cette dernière peut se trouver n'importe où dans le bâtiment.

Plus en détail

Manuel d'utilisation. Module " Gestionnaire "

Manuel d'utilisation. Module  Gestionnaire SphinxOnline Manuel d'utilisation Module " Gestionnaire " Le Sphinx Developpement - Parc Altais - 74650 CHAVANOD France - Tel : +33 (0)4 50 69 82 98 - Fax : +33 (0)4 50 69 82 78 - www.lesphinx-developpement.fr

Plus en détail