Diusion et stockage du nouveau programme

L'exécutiond'unenouvelleapplicationcommenceparladiusionverslenoeudduchierqui

luiestassociéetparsonstockage.Pourcela,ilestnécessairededéniruneméthodedediusion

ecace et robuste pour permettre la reprise de la diusion en cas de perte de connexion, et

pour garantir les données reçues par le noeud. Enn, des limites de taille devront être xées

an de laisserun espace mémoireassez important pour l'utilisateur.

La diusion des données de la nouvelle application se résume à fournir un mécanisme de

fragmentation d'un chier de données complété par une technique de reconstruction sur le

noeud. Pour cela, le protocole LiveNCM-P intègre un champ 'numéro de fragments' dans la

110 octets ce qui permet dans un premiertemps d'envoyer 255 fragments soit une application

d'une taillemaximalede 28 ko. A titre d'exemple, une application simplede relevépériodique

de températureavec lemodule d'administration sans prétraitement des données sera compilée

enun chierbinairede 19ko.Unespaceaumoinséquivalentàcevolumedevraêtreréservépar

l'unité de stockage du noeud. Pour des noeuds ayant peu de ressources mémoire,l'application

seralimitéepar l'espacede stockage de lamise àjourallouablesur lesnoeuds.Parcontre,pour

des noeuds avec d'importantesressources mémoire,une commandesupplémentaire pourra être

incluseande permettre l'envoid'applicationsplusvolumineuses.Cette commandesetraduira

parundécalagedel'indexdesauvegardepermettantainsilaréceptionde255fragmentssupplé-

mentaires. Par ailleurs, an de réduire le nombre de fragments, une technique de compression

sera appliquée sur le code de l'application à transmettre. Le choix de l'algorithme portera sur

ses performances et sur l'utilisation des ressources qu'il nécessite pour s'appliquer. L'impact

sur la communication sera bienentendu une contraintesur ce choix.

Compression des données échangées

Dans lesRCSFs,la réduction des coûts énergétiques passepar des techniques réduisantles

échanges. Il est donc courant de rencontrer la compression de données pour des volumes de

données importants. L'objectif de cette utilisation est de réduire le trac dans les RCSFs en

permettant d'envoyer plus de données en un minimum de messages oud'envoyer des messages

plus courts. Le premier point concerne directement le module de mise à jour. L'idée est de

transmettre une application de taille importante en un minimum de messages vers le noeud.

Nousavonsvuquesanscompressionuneapplicationde28kopouvaitêtretransmisesansnéces-

sité de commande supplémentaire. On peut donc imaginer transmettre plus de données en les

compressant. LiveNCMadonc choisi d'implémenter ettesterdeux algorithmesde compression

de type Human et LZW connus pour leur simplicité de calcul et leur rapidité d'exécution.

L'algorithme de Human permet de coder lescaractères en fonction de leurs occurrences dans

un chier. Un dictionnaire est alors produit en fonction des résultats de la compression puis

transmis vers le destinataire. L'échange du dictionnaire est valable uniquement si le gain de

la compression est au moins supérieur à sa taille. Dans les autres cas, la compression de don-

nées perd de son intérêt. L'algorithme LZW se base sur un codage de chaînes de caractères

récurrentes. Pour chaque nouvelle suitede caractères, un nouveau code est alors produit. Cela

impose alors un codage des caractères sur plus de 8 bits par caractère. Dans ce cas, aucun

dictionnairene sera échangécar lenoeudlereconstitueraaufurà mesurede ladécompression.

Ladiusion d'unemise à jourest un cas d'utilisation très intéressantpour ces algorithmes.La

compression du chier à envoyer est eectuée par le logiciel en charge de gérer les diérentes

versions.Unouplusieursmessages sontalorséchangésavec lenoeudpourluipermettreensuite

de décompresser les données. An d'optimiser l'espace mémoire, la décompression à la volée

des diérentsmessages reçus peutêtre une solutionpourreconstruire,sur lenoeud,lanouvelle

application.Adéfaut d'utilisercemode de décompression,lenoeud devradisposer d'unespace

mémoireau moins deux fois supérieur à lataillede lamise à jour. Ensuite, une étapede véri-

cation de la mise à jour sera nécessaire an de valider la prise en charge par le noeud d'une

Validation du chier reçu

Aujourd'hui,ledéveloppementd'Internetpermetderéaliserdes transfertsdechiersdepuis

desserveurs distantsàdesvitessesimportantessur desréseauxlibresd'accès àtous.Lesrisques

d'erreurs dans la diusion ou les risques de recevoir une application malsaine ont amené à

utiliser des méthodes de vérication robustes des chiers échangés. Dans ce but, l'algorithme

MD5[Rivest 92]aétédéveloppéetutiliséandevérierl'intégritédedonnéestéléchargéespour

prévenir les risques de piratage par exemple. L'algorithme MD5 est une fonction de hachage

cryptographique qui permet d'obtenir l'empreinte numérique d'un chier (en l'occurrence une

séquence de 128 bitsou32caractèresen notationhexadécimale)avec une probabilitétrèsforte

que deux chiers diérents donnent deux empreintes diérentes. Malgré une faille de sécurité

pouvant permettre de reconstituer la même empreinte numérique sur deux chiers diérents,

l'algorithmeMD5est aujourd'huiprésentsurtoutchieroulogicieldetailleimportantecomme

les systèmes d'exploitation libres oucertaines applicationsimportantes. La probabilité d'avoir

une collision de MD5 est alors égale à la probabilité de chaque signature. Pour une signature

128 bits, cette probabilitésera de

1/2

128

soit

2.9 ∗ 10

−39

. Dansles RCSFs,une telle probabilité

constitue un gage de sûreté dans la diusion de chiers volumineux. L'empreinte numérique

est, dans notre cas, calculée sur le chier non compressé an de pouvoir vérier à la fois la

diusion des messages et la décompression des données sur le noeud. Elle est ensuite diusée

vers le noeud qui procédera à la vérication avec celle qu'il aura calculée. Si les données sont

intègres, le noeud autorisera l'utilisation de l'application au prochain redémarrage du noeud

en inscrivantl'adressemémoirede l'applicationdanslastructure d'administration.Danslecas

contraire, un message d'erreur est envoyé vers le logiciel de mise à jour an de recommencer

le processus de diusion. Les données précédemment reçues sont alors écrasées ou eacées du

noeud. Une erreur d'empreinte de chier conduit forcément aurejet de l'application pour des

raisons de sécurité mais aussi pour éliminer tout problème àl'exécution.

Stockage et prise en compte de l'application

Lecouple,algorithmedecompressionetcontrôle d'intégrité,permetde garantirlesdonnées

que le noeud va recevoir. Cependant, une dernière problématique se pose. Le stockage et la

prise en charge de l'application sont deux points durs du module de mise à jour. Les intergi-

ciels présentés dansle chapitre2.2.2 présentent plusieurspistes pour traduirele chier reçu en

application active.La première consisteà implémenterune machine virtuelle sur le noeud an

de traduire les instructions reçues en actions sur le noeud. Cela implique d'ajouter une inter-

face qui coûte des ressources à la fois mémoire et processeur. La deuxième piste proposée est

d'envoyer desmodules compilésqui serontintégrés àl'applicationdéjàembarquée sur lenoeud

par l'intermédiaire d'une interface adaptateur. Ces deux pistes orent une bonne modularité

des programmes embarqués en permettant de modier une partie des fonctionnalités implé-

mentées. Cependant, l'ajoutd'uneinterface(adaptateur oumachinevirtuelle) peut réduireles

performances du noeud et donc celles des applications embarquées. La charge de calcul et de

mémoirepeut devenir importantepour des chiers d'instructionsde grandestailles.

Figure 3.15 Utilisationde lamémoirepar lemodule de mise àjour

chier est alors envoyé en binaire an d'être directement utilisable par le noeud au prochain

redémarrage.Pourcela,ilserastockéen mémoireFlash(mémoireinterne)avantd'êtrepriseen

compte. Leschéma delaFigure3.15présentelesespaces mémoiresmisen oeuvre pourrecevoir

l'applicationetlaprendre encompte. Avantde pouvoirlancerl'application,trois étapesseront

nécessaires au démarrage du noeud. La première consiste à initialiser le fonctionnement du

noeud. Ensuite, le module de mise à jour copiera la nouvelle application en mémoire RAM

(Figure3.15(1))avantdelancerson exécution.Ladernièreétapeconsisteraàplacerlepointeur

d'exécutionaudébutdecettezonemémoire(Figure3.15(2)).Laversionetl'adressedestockage

de l'applicationsontsauvegardées en mémoireFlashduprocesseur. Le noeudn'a plus qu'àlire

cettezonemémoirepoursavoirs'ilyaunemiseàjouràutiliserous'ildoitutiliserleprogramme

de base du noeud.

Avec ce concept de lamise àjour,l'inconvénientmajeurest d'obligerl'utilisateuràenvoyer

l'intégralitédel'applicationpourunesimplecorrectionoupourl'ajoutd'unecommandesimple.

Une solution possible serait d'utiliser des correctifs applicables sur le programme présent sur

le noeud. Lechier reçu ne contiendra queles codes modiés depuis laversion précédente. En

choisissant cette technique, lemodule de mise àjour implémentera un mécanisme pour traiter

les correctifs et les appliquer sur le code. La création d'un correctif commencera par le par-

cours des diérences entre la mise à jour précédente et la future. Le chier résultant décrira

destriplets(adresse/typede modication/corrections)quidevrontêtreappliqués.L'adressedu

caractère serale numérodu caractère dénidepuis ledébutdu chier oùlamodicationdevra

être appliquée. Les opérations possibles seront donc l'insertion, la suppression et la correction

decaractèresoudechaînede caractères.Avec untelmécanisme,lesmisesàjourdecodesn'uti-

tempsdepriseencompteseraaugmenté.Suivantl'opérationàappliquer,lestraitementsseront

plusoumoinscomplexes. Pour limiterl'usurede lamémoireFlash,lesmodicationsseront ap-

pliquées sur une version stockée en mémoire RAM sur laquelle il est possible d'eectuer des

opérations rapides.La version corrigéeviendra ensuite écraser laprécédente version sauvegar-

dée sur le noeud après que le résultat ait été validé via le contrôle d'intégrité du module de

mise àjour.Les correctifsserontdonc principalementutilisés pour des faiblescorrectionspour

lesquelles lenoeud peut agirrapidement etfacilement.Les plus grosses mises àjour passeront

3.4 Conclusion

Le besoin d'administration des RCSFs est une question de recherche actuelle. La diu-

sion, le stockage et le traitement des données par le noeud demande d'avoir de nombreuses

méthodes pour assurer ces fonctionnalités. Comme nous avons pu le voir, répondre aux dif-

férentes contraintes n'est pas chose facile. Les diérentes méthodes et techniques présentées

danslechapitreprécédentapportentdes méthodes intéressantes pourune meilleuregestiondes

ressources et des noeuds. Malheureusement, leur aspect intrusif et peu portable les rend di-

ciles à mettre en oeuvre sur des applications agri-environnementales par exemple. La solution

d'administration LiveNCM proposée et présentée par la Figure 3.16 intègre une partie de ces

méthodes et propose l'utilisationde techniques innovantes comme le diagnostic indirectet les

estimateurs pour limiter son impact sur le fonctionnement général. L'ensemble des messages

échangés servent alors de messages d'administration. Lesestimateurs viennent en complément

pour limiter lesdonnées inutilementenvoyées et pour aider à prédireàcours terme l'évolution

d'une valeur.

Figure 3.16 Architecture complète de lasolutiond'administration LiveNCM

LiveNCMs'appuie surunearchitecturemulti-agent.Lapartiexeavec lesous-agentSNMP

et la passerelle de communication WSG constitue une base stable et robuste sur laquelle les

diérents noeuds du RCSF peuvent compter. Chaque noeud dispose d'un agent embarqué qui

s'intègre à l'application sans en inuencer son fonctionnement. Il est chargé de la gestion des

messages d'administrationet du modulede mise àjour.Lacommunicationest alors conée au

protocoledecommunicationLiveNCM-Pquiaétédéveloppépourrépondreauxproblématiques

de minimisation des données échangées et d'économie d'énergie. Il s'appuie pour cela sur une

optimisation des entêtes de chaque message et sur des techniques de réduction de données

commeles estimateurs etlacompression. LaTable3.1 dresseles caractéristiquesde LiveNCM

face auxautres techniques d'administration utilisant SNMP.

L'architecture d'administration choisie est basée sur une structure hiérarchique en clusters

du RCSF. La possibilité d'exécuter des requêtes sur le noeud est présente sur les diérents

concepts suivant des protocoles de communication divers (SNMP, Propriétaire, LiveNCM-P).

tout instant. Cependant, l'usage qui en est fait, est trop intrusif dans les méthodes vues dans

le chapitre précédent. LiveNCM a fait le choix d'introduire le diagnostic indirect pour limiter

l'intrusiondel'administrationdanslefonctionnementgénéraldel'application.Avec ceconcept,

il y amoins de requêtesvers lenoeud donc une meilleureautonomie.

ToutcommeGUERRILLA,LiveNCMintègredes traitementsautomatisésdecertainstypes

de messagesan delarendreplusexibleetplusréactiffaceauxdiérentsévénementsinterve-

nantsurlenoeudetdansleRCSF.Lesdonnéesd'administrationsont,danslecasde LiveNCM,

stockées sur un seul etmêmeagent SNMPqui seraemployépour lagestionde plusieursRCSF

comportantplusieursnoeudsetcapteurs,contrairementauxautresméthodesoùunagentétait

déployésur chaque noeud.Certains d'entre euxembarquentdes méthodes d'auto-conguration

des réseaux ce qui permet de les réorganiser périodiquement. LiveNCM a fait le choix d'ex-

ternaliser cette partiepour permettre à l'utilisateur d'implanter laméthode de son choixsans

qu'il n'yait à développer une nouvelle version de l'agent embarqué sur lesnoeuds. L'avantage

de procéder de cette manière est de soulager les noeuds de la charge de calcul et de stockage

associéeàl'agentSNMP.Deplus,leformatdesmessages SNMPest inadaptéauxRCSFscarsa

tailleesttropimportante.L'inconvénientd'avoircettestructurecentraliséeest qu'elleintroduit

un goulotd'étranglementauniveaudu sous-agent SNMPce quipeutlesurcharger etaugmen-

ter les collisions et les pertes de messages. Enn, la problématique énergétique est traitée de

diérentes manièresdans chacune de ces méthodes. Si ANMP et SHAMAN ne proposent pas

de politique énergétique avancée, il n'en est pas de même pour GUERRILLA et LiveNCM.

GUERRILA classe ses noeuds par catégorie de ressources an de lisser l'énergie consommée.

Une réorganisation du réseau est alors eectuée périodiquement pour avoir une rotation des

noeuds maîtres.LiveNCM propose une politiqueénergétique adaptable etbaséesur lesremon-

tées d'informations des noeuds. Ce module intégré à la passerelle de communication et piloté

par les paramètres du sous-agent SNMP, surveille les messages transitant an de détecter les

alertes de pannes ou de dysfonctionnements. Toute alerte détectée par la passerelle se traduit

parunmessageréexepermettantd'agirsurunensemblede paramètresdunoeuddontlemode

de fonctionnementpar exemple.

LessolutionsprisespourcomparaisonsontbaséessurunearchitecturesimilaireàLiveNCM,

àsavoirl'utilisationdu protocoleSNMP pouradministrer lesRCSFs.Nousavonspu voiraussi

commentcaractériserunprotocoled'administrationpourcesréseaux.LaTable3.2tentedepré-

senter cesdiérentspointspour cessolutionsd'administration.L'empreintemémoireétantune

contraintetrès importante, certainessolutionsdemandentde disposerde noeudsplus puissants

pour soutenir les fonctions d'administration dans les clusters. LiveNCM et GUERRILLA ont

la particularité de proposer une réponse prenant en compte cette problématique en intégrant,

pour le premier,un développement minimisantl'impact de l'administrationsur le fonctionne-

mentdu noeud et, pour lesecond, une architecture tournée vers l'utilisationd'agentsmobiles.

LarobustesseduprotocoleSNMPn'estplusàprouver,maisuneutilisationatypiquedecelui-ci

le rend moinstolérantaux pannesque sur des applications standards.

Enrésumé,lasolutionLiveNCM proposéepermetde minimiserl'impactdel'administration

surlesressourcesdunoeudtoutenapportantuneinterfacegénériqued'accèsauxdonnéesbasée

Table 3.1 Carte d'identité de lasolution d'administration LiveNCM

ANMP SHAMAN GUERRILLA LiveNCM

Type d'adminis-

tration

Hiérarchique Hiérarchique Hiérarchique Hiérarchique

Sur demande Sur demande Hybride Hybride

Requêtes SNMP ScriptsSSL Requêtes SNMP Requêtes spéci-

ques et agents mo- biles et actions auto- matiques Stockage des données

Décentralisé Décentralisé Décentralisé Centralisé

N agents SNMP N agents SNMP N agents SNMP 1 agent SNMP

Protocole de

communication

SNMP Propriétaire SNMP LiveNCM-P

Auto-

conguration

Clusters aucune Clusters aucune

Méthodes utili-

sées

Mathématique

ougéographique

Basé sur les res-

sources

(Adaptable)

Politiqueénergé-

tique

Simple Simple Avancée Réactive

Classication des noeuds Optimisation des modes et rotation des maîtres de fonctionne- ment

Table 3.2 Caractéristiques des solutions d'administrationbasées sur leprotocole SNMP

ANMP SHAMAN GUERRILLA LiveNCM

Traitements légers - - - ++

Robustesse ettolérance aux pannes + + ++ ++

Réactivité etadaptabilité + + ++ +

Modularité -- -- ++ +

Empreinte mémoire -- -- + ++

est découpée en troisgroupes:lapartieSNMP,lapasserelle decommunicationetenn l'agent

sur le noeud. Le premier permettra de centraliser les données des RCSFs an de fournir à

l'utilisateur la possibilité de les visualiser à l'aide d'outils SNMP standards. La passerelle de

communication WSG vient compléter le protocole SNMP an de fournir une interface entre

le sous-agent et le RCSF. Elle intégrera certaines techniques comme la politique de gestion

énergétique oula synchronisation des noeuds. Ellejouera le rôle de station de base pilotéepar

lesous-agent SNMP,sans pourautantgérerlesdonnéesdes noeuds.Parailleurs,lavérication

des messages transitant permet de garantir les messages arrivant sur le RCSF. Enn, sur les

noeuds, un agent léger est introduit dans l'applicationde base an de traduire lescommandes

d'administrationetdegérerlesmodesdefonctionnementdunoeud.Enn,leséchangesentreles

diérentsnoeudsetlesous-agentSNMPontétéformatéssuivantleprotocoledecommunication

LiveNCM-P. Il a été développé pour respecter les contraintes énergétiques et minimiser les

donnéesnécessairesàladiusiondesmessages.Cecisetraduitparunformatagedesparamètres

de chaque message en optimisant le nombre de bits utiles. De plus, la réduction des volumes

échangésdansleRCSFpassepar deux techniques :l'estimationetlacompression.Lapremière

doit permettre de diuser uniquement les mesures utiles pour reconstruire le signal acquis

(batterie, température, etc.) avec un seuil d'erreurs paramétrable. La compression de données

est principalement employé pour la diusion de gros volume de données an de réduire le

nombre de messages.

Finalement,LiveNCM ore une nouvelle architecture d'administrationintégrantune inter-

face de communication en charge de réaliser des prétraitementssur lesmessages etd'eectuer

Dans le document Supervision de réseaux d'objets intelligents communicants sans fil (Page 99-110)