:: Enseignements :: Master :: M1 :: 2007-2008 :: Architecture et Programmation Réseau ::

Projet de java réseau

Simulateur de réseau de capteurs multimédia

Le but de ce projet est d'étudier le comportement d'un réseau de capteurs multimédia. L'objectif est de modéliser ce genre de réseau, de définir les protocoles d'échanges entre ses éléments, et d'implanter une architecture de simulation d'un tel réseau.

Les capteurs multimédia

Le terme de capteur est a priori très vaste. Il s'agit d'un élément autonome capable d'acquérir des informations. Un capteurs multimédia peut être une webcam, un appareil photo ou un micro qui acquiert des images et/ou du son.

Dans le cadre de ce projet, nous considérons une simple abstraction d'un capteur multimédia comme étant une application qui dispose d'un ensemble d'informations représentant une image ou un son, rafraîchies à intervalle de temps donné. Par exemple, les informations peuvent être des images, avec leurs coordonnées spaciales dans un référentiel commun (e.g. les 2 coins opposés du rectangle de la prise de vue) associées à une information temporelle (la date de la prise de vue).

En situation réelle, les images fournies par les différents capteurs d'une même scène le seraient avec des angles et des distances différentes. Pour simplifier, dans le contexte de ce projet, on considère que tous les capteurs "regardent" la même scène avec le même angle et à la même distance. Néanmoins, chaque capteur ne peut acquérir qu'une partie de la scène (la zone de couverture du capteur). Bien sûr, il est possible que les images acquises par différents capteur se recoupent. La figure ci-dessous illustre un exemple avec 6 capteurs (A, B, C, D, E et F) représentés avec leur "zone de couverture" de la scène en différentes couleurs.

Outre cette capacité à acquérir des images à intervalle de temps régulier, un capteur a la possibilité de communiquer avec d'autres éléments du réseau. Dans le cadre de notre simulation, un capteur sera représenté par une application Java exécutée sur une machine pourvue d'une adresse IP et des couches transports associées (UDP et TCP) dans un réseau local.

Les noeuds du réseau

Dans des situations réelles, les capacités des capteurs sont très variables en terme d'acquisition, de consommation d'énergie et donc d'autonomie, de communication (débit de transmission), etc. Dans ce projet, nous modéliserons ces différences par plusieurs (au moins deux) niveaux de "tiers". Les capteurs du 1er tiers (de base) sont simplement capables de transmettre (tout ou une partie) des informations qu'ils capturent (A, B, C, D en sont des exemples dans la figure).

Les capteurs d'un tiers de niveau plus élevé peuvent en plus effectuer des opérations liées à la communication dans le réseau de capteurs (router des requêtes, des réponses, optimiser ou répartir le traffic...)

Un noeud particulier dans le réseau est appelé sink, ou "puits". C'est lui qui est l'initiateur des requêtes et qui reçoit finalement les données. On peut considérer qu'il est l'utilisateur final du réseau de capteurs. Typiquement, le puits souhaite visualiser les images correspondant à une zone de la scène, et émet une ou des requêtes en ce sens.

Un réseau collaboratif

En général, chaque capteur émet régulièrement des informations concernant son état et ses capacités: s'il est en veille ou non, quelle est la zone de la scène qu'il couvre, quelle est la fréquence de raffraîchissement de ses images, quelle est sa disponibilité (c'est à dire la charge de travail qu'il accomplit actuellement), quel est son débit de communication disponible, etc. Ces informations transmises par les capteurs sont appelées des descripteurs.

Les destinataires des descripteurs, comme l'ensemble des communications possibles dans un réseau de capteurs, dépendent du modèle de communication considéré.

Dans un réseau hiérarchique, comme celui représenté dans la figure, les communications n'ont lieu qu'entre parents et enfants. Les capteurs de 1er tiers (de base, comme A, B, C ou D) se contentent d'émettre des descripteurs, de recevoir et de répondre aux requêtes. Les capteurs d'un tiers supérieur pourront également communiquer avec leur parent ou leurs enfants, mais pourront également router des informations ou tenter d'optimiser le traffic, réaliser des traitements sur les images (agrégation de données...), etc.
Dans un réseau maillé (mesh), on peut imaginer que les lignes de communication ne constituent pas un arbre mais un graphe. Dans la figure, par exemple, E et F pourraient communiquer entre eux.

Au delà des simples échanges de descripteurs, un réseau de capteurs doit être capable de satisfaire une ou plusieurs requêtes de l'utilisateur. Différentes problématiques classiques sont alors rencontrées:

Une requête donnée peut-elle être satisfaite par un réseau dans un état donné (en fonction de la charge de chacun des noeuds devant participer à la satisfaction de la requête, des débits autorisés, etc.)? C'est la problématique de l'admission d'un flux.
Comment peut on optimiser une requête, en particulier dans le cas où plusieurs capteurs peuvent transmettre une même zone d'image requise? C'est une problématique d'optimisation "métier": le découpage d'une image et sa reconstitution, sur un noeud intermédiaire ou à l'arrivée...
Dans le cas d'un réseau maillé, l'existence de plusieurs routes entre les points d'acquisition d'une image et le puits peut permettre de répartir les charges sur les différents liens de communication. C'est la problématique de l'équilibrage de charge.

Un des objectifs de ce projet est de perçevoir ces différentes problématiques et de tester différentes approches pour les résoudre dans un contexte simulé.

La simulation

Afin de simuler le réseau de capteurs et les différentes stratégies de communication pour satisfaire les requêtes, nous souhaitons pouvoir utiliser différentes machines disposant des moyens d'adressage et de communication TCP/UDP-IP, sur lesquelles s'exécuteront des applications Java représentant des capteurs.

Deux "simulateurs" seront utilisés.

Un simulateur des données captées. Plutôt que chaque application représentant un capteur dispose d'un mécanisme permettant de capturer de l'image et du son, ces données multimédia lui seront directement fournies par un serveur. Le même serveur pourra ainsi fournir les données utilisables par chaque capteur. En pratique, chaque capteur représenté par une application Java sur une machine récupérera les données qu'il est sensé "capturer" sur un même serveur de données.
Un simulateur de configuration et superviseur. Plutôt que de devoir administrer, paramétrer et superviser localement et indépendament chaque [application simulant un] capteur, ces opérations de paramétrage, configuration et supervision des différents capteurs seront réalisées à distance par un superviseur. En pratique, chaque capteur représenté par une application Java sur une machine communiquera avec un même serveur de supervision.

Le travail demandé

Le travail demandé se décompose en trois applications distinctes et trois protocoles de communication.

Les capteurs. Cette application Java peut en réalité être de différente nature.
- un capteur de premier tiers, le plus basique;
- un capteur d'un tiers plus élevé, avec des fonctionnalités avancées (on pourra a priori se limiter à deux ou trois niveaux de tiers).
- un puits, ou sink, émetteur des requêtes et destinataire des réponses du réseau (en général, un puits n'est pas nécessairement un capteur mais vous pourrez décider ou non d'en faire par nature un élément distinct du réseau).
Un serveur de supervision. Cette application Java doit permettre d'enregistrer les capteurs du réseau qui seront "démarrés" sous la forme d'une application Java sur une machine. Lors de cet enregistrement, c'est le serveur de supervision qui sera en charge de fournir au capteur la totalité de ses paramètres de fonctionnement (zone de couverture, capacité, liens de communications avec ses voisins, etc.). En outre, au cours de la vie du capteur, le serveur de supervision devra pouvoir configurer dynamiquement l'état de ce capteur (le mettre en veille, le réveiller, l'arrêter, le redémarrer, modifier sa zone de surveillance, l'état de ses liens de communication, etc.). Il devra également pouvoir récupérer différentes informations du capteur (état, charge actuelle, autonomie, etc.). Le serveur de supervision sera le point unique d'utilisation du simulateur de réseau de capteurs: l'utilisateur du simulateur devra pouvoir manipuler une interface de configuration interactive (pour configurer ou superviser tel ou tel capteur, pour faire émettre une requête par le puits ou en récupérer le résultat...) ou encore faire "jouer" un scénario décrit par avance sous la forme d'un fichier.
Un serveur de données. Cette application Java se contente de fournir à chaque capteur qui la sollicite le flux de données multimédia qui le concerne (correspondant à sa zone de couverture, à sa capacité, à sa résolution, etc.).
Un protocole de supervision. Celui-ci doit décrire le format des données qui sont échangées entre le serveur de supervision et les capteurs.
Un protocole de transmission des données. Celui-ci doit décrire le format des données qui sont échangées entre le serveur de données et les capteurs.
Un protocole de communication. Celui-ci doit décrire le format des données qui sont échangées entre les capteurs dans le réseau, que ce soit pour transmettre des descripteurs, des requêtes, des réponses, optimiser de trafic ou le routage, etc. La spécificité de ce protocole est qu'il doit pouvoir être conservé au niveau du réseau de capteurs même dans le cas où ce dernier n'est plus simulé. Autrement dit, en l'absence des deux serveurs de données et de supervision, le protocole de communication doit rester valable et permettre le fonctionnement d'un réseau de capteurs réels (webcams...) offrant la possibilité à un puits d'émettre des requêtes et de reçevoir les informations correspondantes.

L'ordre dans lequel les applications et les protocoles sont listés ci-dessus est quelconque. Néanmoins, il convient de considérer que le protocole de communication et les applications des capteurs (et du puits) qui implémentent ce protocole sont les éléments "de base" du réseau.

En plus de l'implémentation du protocole de communication, pour que le simulateur du réseau soit opérationnel, les capteurs devront implanter les protocoles de transmission des données et de supervision et les serveurs respectifs devront être implantés.

Pré-rendu

Le projet est à réaliser par groupes de 4 personnes (un seul groupe de 3 personnes est autorisé, pour lequel l'évaluation sera un peu plus indulgente).

Pendant deux semaines, vous devrez réfléchir à l'architecture de vos applications et aux différents protocoles qu'elles utilisent. Rien ne vous empêche de réaliser des petits prototypes pour valider la faisabilité de telle ou telle fonctionnalité (c'est même fortement conseillé), mais il ne vous sera pas demandé de rendre de code à cette étape.

Pour le 10 mars 2008 10h00 au plus tard, vous devrez fournir les descriptions des trois protocoles, au format RFC (en anglais et en ASCII - mode texte, 15-20 pages maximum pour chaque protocole). Chaque RFC doit établir clairement l'objectif du protocole, son principe de fonctionnement et le format des données qui sont échangées (protocole de transport utilisé, format, encodage, codes d'opérations, etc.). Elle ne doit en aucun cas faire des hypothèses sur la manière de réaliser une implantation de ce protocole, ni en terme de langage de programmation, ni en terme d'architecture de l'application.

Ces documents seront envoyés par mail aux enseignants de la matière avec comme sujet "PreRendu Java Reseau M1" et dans le corps du mail les noms et prénoms des différents membres du groupe. Les noms des fichiers de rfc devront respecter la convention suivante, et chaque rfc devra contenir au début les noms et prénoms des auteurs:

rfcData.txt pour le protocole de transmission des données entre les capteurs et le serveur de données.
rfcSupervision.txt pour le protocole régissant les échanges entre les capteurs et le serveur de supervision.
rfcSensors.txt pour le protocole de communication entre les capteurs dans le réseau.

Rendu final

Pendant les quatre semaines suivantes, vous devrez réaliser des applications Java pour le serveur de supervision, pour le serveur de données et pour les capteurs. En matière de communication, ces applications devront respecter scrupuleusement les RFCs que vous avez établies pour le pré-rendu. Dans le cas où les RFCs initialement définies ne permettraient pas aux applications de fonctionner et nécessiteraient des révisions, vous formaliserez les nouvelles révisions et détaillerez dans un document annexe l'ensemble des évolutions avec leur justification.

Pour le 9 avril 2008(date limite repoussée d'une semaine) au plus tard, vous devrez fournir l'intégralité de votre projet sous la forme d'une archive au format zip (tout rar, tar.gz, 7z et autre ne sera pas ouvert) contenant:

un répertoire src contenant les sources du projet et les éventuelles ressources (images, sons, etc.) à recopier à côté des classes;
un répertoire docs contenant un manuel de l'utilisateur (user.pdf) permettant d'installer, prendre en main et utiliser vos applications ainsi qu'un manuel qui explique votre architecture (dev.pdf), les deux manuels au format PDF;
un répertoire rfc contenant les trois rfc originales rfcData.txt, rfcSupervision.txt et rfcSensors.txt telles qu'elles ont été livrées lors du pré-rendu (format texte ASCII). Dans le cas où des modifications auraient dû être effectuées sur l'une ou l'autre des rfc dans le cadre des implantations, vous fournirez pour chacune des rfc modifiées sa nouvelle version en respectant la convention de nommage rfcData.revision.txt, rfcSupervision.revision.txt et rfcSensors.revision.txt ainsi qu'un document evolutions.pdf justifiant chacune des modifications que vous avez été contraint d'apporter.
des jar exécutables supervisor.jar pour le serveur de supervision, dataserver.jar pour le serveur de données et sensor.jar pour les capteurs.
un build.xml qui permet de
- compiler les sources (target compile)
- créer les jar exécutables nécessaires (target jar)
- générer la javadoc dans docs/doc (target javadoc)
- nettoyer le projet pour qu'il ne reste plus que les éléments demandés (target clean)
un répertoire lib contenant les éventuelles bibliothèques dont a besoin votre projet pour fonctionner.

Cette archive zip aura comme nom Nom1Nom2Nom3Nom4_Sensor.zip, où les noms sont ceux des membres du groupe par ordre alphabétique. L'extraction de cette archive devra créer un répertoire de nom Nom1Nom2Nom3Nom4_Sensor pour contenir tous les éléments demandés ci-dessous. Elle sera envoyée par mail aux enseignants de la matière, avec dans le corps du message les noms et prénoms de chacun des membres du groupe.

Soutenance

Lors de votre soutenance (qui aura lieu le 9 avril 2008 à partir de 14h00), vous devrez utiliser l'archive zip rendue par mail et présenter une démonstration que vous aurez préparée et testée dans les salles de TP de l'école et qui utilise au moins 4 machines distinctes: une pour le superviseur, une autre pour le serveur de données et enfin deux autres machines pour différents capteurs (une machine doit impérativement pouvoir héberger plusieurs capteurs). Après le lancement des différentes applications, seule la machine hébergeant le superviseur sera utilisée pour la démonstration.