FR 2861864 A1 20050506 FR 0312869 A 20031103 La présente invention concerne un procédé de notification de changements d'état des ressources d'un réseau, à destination d'au moins une application adaptée pour s'exécuter sur ce réseau. L'invention concerne également un programme d'ordinateur et un système de notification de changements d'état pour la mise en oeuvre de ce procédé. Ce type de procédé est généralement mis en oeuvre pour des applications sensibles aux changements d'état du réseau sur lequel elles s'exécutent. Ces applications logicielles réalisent en général des services vitaux du réseau, parmi lesquels la découverte de ressources du réseau (applications JINI , UpnP , Salutation , SLP), la gestion de qualité de service, ou encore la gestion de groupe (système HORUS ). Les changements d'état du réseau pouvant intéresser ces applications comprennent par exemple la disparition, la réapparition d'un noeud du réseau, le déplacement d'un noeud à l'intérieur du réseau, ainsi que des informations de qualité de service telles que les changements de capacité des liens ou des noeuds traversés (bande passante, capacités de calcul, batteries, etc.). On connaît déjà dans l'état de la technique un procédé du type précité. Dans le cas de l'application JINI , un annuaire de services appelé Lookup Server maintient à jour une liste de serveurs applicatifs disponibles du réseau, à l'aide d'un procédé de rafraîchissement (appelé couramment mécanisme de leasing ). Selon ce procédé de rafraîchissement, les serveurs applicatifs doivent périodiquement renouveler leur abonnement à l'annuaire de services en lui signalant qu'ils sont toujours opérationnels, sans quoi, ils sont automatiquement supprimés de la liste. Cette solution qui fonctionne correctement dans un réseau filaire classique dont les noeuds, les liens et les serveurs applicatifs sont relativement stables, est beaucoup moins adaptée à un réseau ad-hoc, c'est-à-dire un réseau ne comportant pas d'infrastructure prédéterminée, dans lequel on ne dispose en outre que d'une bande passante limitée et dans lequel les noeuds sont potentiellement mobiles, peuvent servir en même temps à exécuter des applications et possèdent des caractéristiques variées en terme d'autonomie, de capacités d'exécution et de bande passante. En effet, dans ce type de réseaux sans infrastructure, si l'on souhaite appliquer ce mécanisme de rafraîchissement pour le bon fonctionnement de l'application d'annuaires de services de JINI , le paramètre d'intervalle de temps entre deux rafraîchissements doit être réglé à une valeur suffisamment faible pour compenser les modifications incessantes de la constitution du réseau. D'un autre côté plus cet intervalle de temps est faible, plus la bande passante occupée pour véhiculer ces informations dans le réseau ad-hoc est importante, ce qui pose problème pour un réseau dans lequel cette ressource est limitée. De même, pour des applications de type gestion de groupe , des échanges d'informations doivent être régulièrement véhiculés à travers le réseau ad-hoc entre les noeuds de ce réseau, pour maintenir à jour les informations concernant le groupe géré par l'application. Cette information génère également un flux supplémentaire à travers le réseau ad-hoc dont la bande passante est limitée. Pour des applications sensibles à la qualité de service, telles que les applications multimédia, des informations sur les capacités des liens et des noeuds traversés doivent être échangées entre les noeuds pour identifier et surveiller les chemins respectant les conditions de qualité de service requises par les applications. Des changements d'état peuvent intervenir lors de la mobilité d'un noeud, lors de l'usage d'un noeud autrement que pour transmettre les données des autres noeuds, ou encore lorsqu'un noeud passe en mode d'économie d'énergie. De tels changements pouvant avoir un impact sur la qualité de service négociée avec les applications, il est préférable que ces applications en soient notifiées avant qu'elles ne le détectent elles-mêmes afin de ne pas dégrader la qualité de service ou interrompre le service. L'invention vise à remédier à ces inconvénients en fournissant un procédé de notification de changements d'état capable de fournir aux applications adaptées pour s'exécuter sur un réseau, des informations sur les changements d'état de ce réseau, en limitant le plus possible le surcoût dû à la transmission de ces informations dans le réseau. L'invention vise ainsi à fournir un procédé de notification particulièrement adapté aux réseaux de type ad-hoc. L'invention a donc pour objet un procédé de notification de changements d'état des ressources d'un réseau, à destination d'au moins une application adaptée pour s'exécuter sur ce réseau, caractérisé en ce qu'il comporte les étapes suivantes: - extraction d'informations de routage par des moyens de notification de changements d'états auprès desquels l'application a été préalablement enregistrée; - transmission de ces informations de routage extraites par les moyens de notification, à destination de l'application. En effet, les protocoles de routage mis en oeuvre dans tout réseau, et notamment dans les réseaux ad-hoc, génèrent un trafic permettant de connaître l'état du réseau et de mettre à jour les informations concernant cet état. Ces informations peuvent concerner un changement de bande passante, dû aux interférences radio entre plusieurs noeuds co- localisés, ou un changement des capacités de routage d'un noeud traversé, dû à l'utilisation de ce noeud pour effectuer des traitements applicatifs ou à une économie d'utilisation de ce noeud pour réduire sa consommation d'énergie lorsqu'il fonctionne sur batterie. L'invention permet donc d'utiliser ces informations de routage pour les transmettre aux applications adaptées pour s'exécuter sur le réseau, sans que ces applications n'aient besoin de vérifier d'elles-mêmes l'état des noeuds du réseau avec lesquels elles communiquent lorsqu'elles sont exécutées. Ainsi, pour des applications telles qu'un annuaire de services ou une application de découverte des services (JINI ), les mécanismes de rafraîchissement classiques peuvent être remplacés par la transmission d'au moins une partie des informations de routage aux applications intéressées. De même, pour une application de type gestion de groupe, les informations de routage du réseau peuvent renseigner sur l'état du groupe et peuvent donc être transmises, sans surcoût dans le réseau et avec une simplification des applications adaptée pour s'exécuter sur le réseau. De plus, pour une application multimédia, les informations de changements d'états du réseau transmises à l'application lui permettent de s'adapter, par exemple pour redéfinir son contrat de qualité de service. L'invention permet donc l'extraction d'informations en général échangées à des niveaux du réseau chargés du routage des informations véhiculées, pour les transmettre à des niveaux supérieurs dans lesquels sont gérées les exécutions des applications elles-mêmes. Un procédé de notification de changements d'état selon l'invention peut en 20 outre comporter l'une ou plusieurs des caractéristiques suivantes: lors de l'étape préalable d'enregistrement, on sélectionne une partie des noeuds et/ou des liens du réseau de sorte que les informations extraites et transmises à cette application sont des informations de routage concernant cette partie des noeuds et/ou des liens sélectionnés; - le réseau est un réseau ad-hoc, et l'extraction des informations de routage est réalisée par l'interrogation d'un protocole de routage mis en oeuvre dans le réseau ad-hoc; - les informations de routage sont extraites de tables de routage échangées par un protocole de routage pro-actif du réseau ad-hoc, notamment le protocole OLSR; et - le procédé comporte en outre une étape d'extension dynamique des moyens de notification lors de laquelle, de nouvelles informations de routage étant déployées sur le réseau, on introduit de nouvelles règles d'extractions correspondantes dans les moyens de notifications. Un avantage du protocole OLSR est qu'il permet effectivement une telle extension 35 dynamique des moyens de notification. Dans un réseau proactif, un paquet échangé entre deux routeurs peut non seulement véhiculer des données mais également des programmes. Ce procédé est par exemple réalisable grâce à la technologie de téléchargement de code JAVA appelée OSGi . L'invention concerne également un programme d'ordinateur pour la notification de changements d'état des ressources d'un réseau, à destination d'au moins une application adaptée pour s'exécuter sur ce réseau, caractérisé en ce que, l'application ayant été préalablement enregistrée auprès du programme d'ordinateur, il comporte des moyens d'extraction d'informations de routage et des moyens de transmission de ces informations extraites à destination de l'application. Enfin, l'invention concerne également un système de notification de changements d'état des ressources d'un réseau, comportant le réseau et au moins une application adaptée pour s'exécuter sur ce réseau, caractérisé en ce qu'il comporte un programme d'ordinateur tel que décrit précédemment, installé sur au moins l'un des noeuds du réseau. L'invention sera mieux comprise à l'aide de la description qui va suivre, donnée uniquement à titre d'exemple et faite en référence aux dessins annexés dans lesquels: - la figure 1 représente schématiquement la structure d'une installation selon l'invention; et - la figure 2 représente les éléments fonctionnels d'un serveur mettant en oeuvre un procédé selon l'invention. L'installation représentée sur la figure 1 comporte un réseau ad-hoc 10 constitué de noeuds 12, 14 et de liens entre certains des ces noeuds. Un réseau ad-hoc est constitué de noeuds mobiles ou fixes ayant la propriété de constituer automatiquement et dynamiquement un réseau capable d'acheminer des paquets d'un point quelconque du réseau à un autre dès lors qu'une communication radio s'établit entre chaque noeud et ses voisins. Chaque noeud 12, 14 est un dispositif électronique capable de communiquer a priori avec les autres noeuds du réseau, si ceux-ci sont reliés soit directement, soit indirectement (par exemple par des relations de voisinages de proche en proche) à ce dispositif. Par exemple les noeuds du réseau ad-hoc sont constitués de dispositifs tels qu'un assistant numérique personnel, un téléphone mobile, un micro-ordinateur sans fil, etc. Pour pouvoir faire partie du réseau ad-hoc 10, chaque dispositif 12, 14 est muni d'applications de routage conformes à un protocole commun 12b, 14b de couche réseau ou transport dans le système OSI, pour le routage des données dans le réseau ad-hoc. Ce protocole est par exemple le protocole pro-actif OLSR, qui est adapté pour l'échange périodique de tables de routage entre les noeuds du réseau. Ainsi, chaque noeud du réseau ad-hoc remplit également une fonction de routeur pour la transmission des informations d'un point à un autre du réseau. De plus, chacun des noeuds 12, 14 du réseau ad-hoc 10 comporte éventuellement des applications conformes à un protocole 12a, 14a de couche application dans le système OSI, utilisant par exemple la technologie JINI . Pour la mise en oeuvre d'un partage de ces applications, le réseau ad-hoc 10 comporte un noeud 14 particulier, remplissant une fonction de serveur de gestion des applications. A cette fin, le serveur 14 comprend, outre des applications de routage conformes au protocole commun 14b de couche réseau ou transport et des applications conformes au protocole 14a de couche application, des moyens de notification 14c intermédiaires entre ces applications. Les moyens de notification 14c ont pour fonction d'extraire des informations de routage échangées par les applications de routage (par exemple les tables de routage OLSR), pour les transmettre à des applications JINI qui se sont préalablement enregistrées. Ils notifient ainsi les applications concernées de changements d'état des ressources du réseau ad-hoc. Comme cela est représenté sur la figure 2, le serveur 14 de gestion des applications comporte des applications conformes à un protocole commun 14d de couche physique pour l'échange de données entre ce serveur et les autres noeuds du réseau ad-hoc 10. Les fonctions de routage conformes au protocole 14b du serveur d'application 14 comprennent des moyens 16 de filtrage d'événements issus de la couche 14d, pour fournir une partie de ces événements, en particulier ceux concernant le routage, vers des moyens d'analyse 18. Ces événements sont traités par les moyens d'analyse 18 de telle sorte que ceux-ci les transmettent sous forme d'informations de changement de topologie à des moyens 20 de mise à jour de la topologie du réseau ad-hoc 10. La façon dont les moyens de filtrage 16, d'analyse 18 et de mise à jour 20 fonctionnent et interagissent est classique. Elle ne sera donc pas détaillée. Les moyens 20 de mise à jour de la topologie du réseau ad-hoc 10 peuvent en outre extraire une partie des événements directement de la couche 14d. Leur fonction est de fournir des tables de routage qui sont ensuite régulièrement échangées entre les noeuds du réseau ad-hoc. Les moyens de notification 14c sont implémentés en tant qu'intermédiaires entre les applications de routage de la couche 14b et les applications JINI de la couche 14a. Ces moyens de notification 14c comprennent des premiers moyens 22 d'extraction d'informations de routage à partir des moyens de mises à jour de la topologie du réseau 20. En particulier, les informations de routage sont extraites directement des tables de routage OLSR dans le cas de cet exemple de réalisation. Le protocole OLSR permet aussi une extension dynamique des moyens de notification 14c lors de laquelle, de nouvelles informations de routage étant déployées sur le réseau 10, on introduit de nouvelles règles d'extractions correspondantes dans les moyens de notifications. Les informations extraites par les moyens 22 sont ensuite transmises à des moyens 24 de transmission de ces informations à différentes applications s'étant préalablement enregistrées auprès des moyens de notification 14c. Ces applications comprennent par exemple un annuaire de services 26, du type Lookup Server ou d'autres applications mises en oeuvre par la technologie JINI . Ces applications peuvent également comprendre une application de gestion de groupe 28. Lors d'une étape préalable, chacune des applications JINI de la couche 14a intéressées par la réception des notifications d'événements, s'inscrit auprès des moyens de transmissions 24, pour indiquer le type d'informations qui l'intéresse, c'est-à-dire notamment les informations concernant les noeuds du réseau susceptibles d'avoir une influence sur la mise en oeuvre de l'application considérée. Ces informations extraites par les moyens d'extraction 22 sont obtenues soit directement à partir des tables de routage comme indiqué précédemment, lorsque des protocoles pro-actifs comme le protocole OLSR sont mis en oeuvre, soit à l'aide d'interfaces spécifiques créées pour interroger les protocoles de routage mis en oeuvre par le réseau ad-hoc, notamment par exemple dans le cas de protocoles de routage ré-actifs. Il apparaît clairement qu'un procédé et un système de notification d'événements tels que décrits précédemment, permettent d'informer les différentes applications mises en oeuvre dans le réseau ad-hoc, des noeuds du réseau ad-hoc disponibles ou indisponibles, en temps réel, et ceci sans surcharge de la bande passante, puisque seules sont utilisées les informations de routage qui sont de toute façon véhiculées en permanence dans le réseau ad-hoc. On notera enfin que l'invention n'est pas limitée au mode de réalisation décrit 30 précédemment. En variante notamment, les applications susceptibles d'être notifiées selon ce procédé peuvent être conformes à d'autres technologies que la technologie JINI . REVENDICATIONS 1. Procédé de notification de changements d'état des ressources d'un réseau (10), à destination d'au moins une application (26, 28) adaptée pour s'exécuter sur ce 5 réseau, caractérisé en ce qu'il comporte les étapes suivantes: - extraction (22) d'informations de routage par des moyens (14c) de notification de changements d'état auprès desquels l'application a été préalablement enregistrée; - transmission (24) de ces informations de routage extraites par les moyens 10 de notification, à destination de l'application. 2. Procédé de notification de changements d'état selon la revendication 1, caractérisé en ce que, lors de l'étape préalable d'enregistrement, on sélectionne une partie des noeuds et/ou des liens du réseau (10) de sorte que les informations extraites et transmises à ladite application (26, 28) sont des informations de routage concernant cette partie des noeuds et/ou des liens sélectionnés. 3. Procédé de notification de changements d'état selon la revendication 1 ou 2, caractérisé en ce que le réseau (10) est un réseau ad-hoc, et en ce que l'extraction des informations de routage est réalisée par l'interrogation d'un protocole de routage (14b) mis en oeuvre dans le réseau ad-hoc. 4. Procédé de notification de changements d'état selon la revendication 3, caractérisé en ce que les informations de routage sont extraites de tables de routage (20) échangées par un protocole de routage pro-actif du réseau ad-hoc, notamment le protocole OLSR. 5. Procédé de notification de changements d'état selon l'une quelconque des revendication 1 à 4, caractérisé en ce qu'il comporte en outre une étape d'extension dynamique des moyens de notification (14c) lors de laquelle, de nouvelles informations de routage étant déployées sur le réseau (10), on introduit de nouvelles règles d'extractions correspondantes dans les moyens de notifications (14c). 6. Programme d'ordinateur (14c) pour la notification de changements d'état des ressources d'un réseau (10), à destination d'au moins une application (26, 28) adaptée pour s'exécuter sur ce réseau, caractérisé en ce que, l'application ayant été préalablement enregistrée auprès du programme d'ordinateur, il comporte des moyens (22) d'extraction d'informations de routage et des moyens (24) de transmission de ces informations extraites à destination de l'application. 7. Système de notification de changements d'état des ressources d'un réseau (10), comportant le réseau (10) et au moins une application (26, 28) adaptée pour s'exécuter sur ce réseau, caractérisé en ce qu'il comporte un programme d'ordinateur (14c) selon la revendication 6, installé sur au moins l'un des noeuds (14) du réseau.