I. Présentation générale de l’ANTS

1. Le concept de réseau actif

Lancé en 1996, le concept de réseau actif rompt la vision des réseaux informatiques dans lesquels les différents équipements traversés par des paquets de données effectuent les mêmes traitements sur ces derniers en respectant en général un protocole unique. Par opposition à cette approche figée, le concept de réseau actif permet à un utilisateur et/ou une application de déployer dynamiquement du code spécifique dans les nœuds du réseau traversés par ces paquets. Cela permet de personnaliser à différentes échelles les services et protocoles du réseau et offre une vision dynamique très prometteuse de l'évolution de ces mêmes services et protocoles. Si cette approche est intéressante, elle ouvre de nombreux problèmes de recherche qui à ce jour, dépassent ses avantages. Ce domaine est de ce fait un formidable champ d'expérimentation pour les chercheurs en réseaux et télécommunications.

Les problèmes ouverts dans le domaine des réseaux actifs sont nombreux. Cinq points sont aujourd'hui largement étudiés :

• Architecture : il faut arriver rapidement à définir une architecture générique d'un nœud actif et fournir un format unique pour les paquets actifs échangés entre les nœuds. Cette architecture doit également prendre en compte l'ensemble des facilités pour déployer des environnements d'exécution sur des nœuds actifs.

• Supervision : le déploiement des réseaux actifs fait intervenir de nombreux paramètres peu exploités à ce jour dans la supervision et le contrôle des réseaux. On retrouve notamment la notion d'usager qui est amenée jusqu'au niveau de l'équipement et du code de l'usager sur l'équipement. Un travail de recherche est à développer sur la supervision de ce type de réseau.

• Spécification : la spécification de réseaux actifs et de protocoles actifs amène de nouveaux défis aux techniques de description formelle traditionnellement utilisées dans les réseaux. Parmi ces défis, on trouve le support de la spécification de la mobilité, la modification dynamique d'un protocole sur un nœud, la description des propriétés sur des protocoles multiples…

• Sécurité : permettre à des utilisateurs de déployer du code sur des équipements intermédiaires du réseau implique la mise en place de solutions garantissant la sécurité du code des usagers, la sécurité des équipements et des mécanismes de garantie de l'intégrité du code déployé ainsi que de l'authentification des usagers.

• Applications : si le concept de réseau actif est intéressant à priori, il doit impérativement faire ses preuves en démontrant son intérêt pour des applications et des domaines d'applications précis. Aujourd'hui seule la gestion et la communication de groupes apparaissent clairement comme des domaines fertiles pour les réseaux actifs.

2. Les différentes sortes de réseau actif

Outre l’ANTS, que nous présenterons en détail dans les prochains paragraphes, il existe d’autres sortes de réseaux actifs.

· “ Unix in every router ”:

Lampson a décrit un réseau actif comme étant un réseau dans lequel Unix est installé dans chaque routeur de ce réseau. Cette approche globale suppose la flexibilité d’un système partagé. De nouvelles fonctionnalités peuvent être téléchargées dans les routeurs comme des composants distribués et exécutés comme des processus communiquant par l’échange de messages.

• Le Firewall “ intelligent ” :

Une autre approche est de permettre aux utilisateurs de modifier des équipements spécialisés du réseau. Les Firewalls en sont un bon exemple : en effet ces derniers effectuent un filtrage des données d’une application tant qu’ils traitent les paquets. L’intérêt du firewall intelligent est de permettre aux utilisateurs de contrôler ce filtrage afin de permettre un contrôle sur les services qui sont exportés. L’Active Bridge est un exemple de cette approche. Mais qui sera capable de reprogrammer des fonctionnalités sans connaître le routage et les équipements actifs ? L’avantage de l’ANTS est de fournir un modèle de programmation qui permettra aux utilisateurs d’exploiter le réseau dans son ensemble.

• La signalisation

Plutôt que du transfert de données, utiliser le réseau actif pour de la signalisation.

En plus d’établir une connexion traditionnelle, cela permettra aux utilisateurs de pouvoir en même temps scruter plus facilement l’état du réseau, pour connaître par exemple les différentes ressources, faire des diagnostics, connaître l’état du trafic….

3. La plate-forme ANTS

Ants pour "Active Node Transfer System", est une plate-forme permettant la mise en place et le déploiement dynamique de protocoles. ANTS fournit un modèle de programmation qui aide au développement de nouveaux protocoles, un système permettant de faire fonctionner le nouveau protocole à l'intérieur du réseau, et un nœud sur lequel s'exécute le protocole.

a) Objectif d'ANTS

ANTS est destinée à supporter de nouveaux services de réseaux pour router, rassembler, filtrer… les paquets de données à l'intérieur du réseau.

Ceci implique la notion de protocoles pour application spécifique où des morceaux de traitement sont effectués à des endroits stratégiques du réseau : les nœuds actifs.

2 objectifs principaux pour rendre le réseau actif :

¨ Les nœuds du réseau doivent supporter différents protocoles ( pouvant être utilisés simultanément )

¨ Les nouveaux protocoles doivent être compris par le réseau.

b) Les caractéristiques de l’ANTS 

· Les paquets contiennent des références sur leur routage (adresse de destination) pour ensuite être traités par les nœuds du réseau. Ceci permet aux utilisateurs du réseau de contrôler les paquets qu’ils envoient mais pas les paquets qu’ils reçoivent.

· Chaque routage correspondra à un traitement différent sur des nœuds actifs différents. Par exemple un groupe de nœuds pourra être approprier à des adresses particulières.

Mais il est clair que le réseau doit assurer outre une certaine flexibilité, une protection, une optimisation de l’allocation des ressources et de meilleures performances ( but premier du réseau actif ).

La protection est basée sur la capacité à spécifier le traitement pour ses paquets uniquement. C’est à l’utilisateur de protéger ses paquets.

L’allocation est basée sur les ressources qui seront accordées pour chaque paquet par les nœuds.

La performance dépend du traitement effectué en chaque nœud et de la façon dont on a utilisé les nœuds, en ce sens que pour une application il n’est pas nécessaire de rendre tous les nœuds actifs. On parle ainsi de nœuds stratégiques.

c) L’architecture de l’ANTS

Un réseau ANTS consiste à interconnecter un groupe de nœuds qui exécute un “ runtime ” ; les nœuds pourront être connectés à travers un réseau local ou étendu et en liaison point à point ou par partage de canaux médium.

Le système offre sur la couche liaison des canaux pour fournir sur la couche réseau des applications.

A l’inverse d’un réseau IP, le service fourni par l’ANTS n’est pas fixe mais flexible ; c’est à dire que l’utilisateur pourra rendre dynamique le traitement d’une application. Différentes applications sont capables d’introduire de nouveaux protocoles dans le réseau. Les nœuds du réseau doivent simultanément supporter une variété de différents protocoles du réseau.

Voici la figure hiérarchique qui compose l’ANTS :

d) Protocoles et capsules

Un “ code group ” est un ensemble de capsule dont le routage est le même. Ces mêmes adresses sont transférées par le système de distribution de code.

Un protocole est un ensemble de “ code groups ” qui sont traités comme une simple unité de protection par les nœuds actifs.

e) Le “ Code distribution ”

Le système de code distribution est un mécanisme propageant des programmes au bon endroit. Le cas extrême est d’inclure des exécutables dans toutes les capsules.

Mais l’approche de l’ANTS a été de coupler le transfert de code avec le transfert de données. Cela permet de limiter la distribution de code uniquement vers les nœuds nécessitant ce code exécutable

A chaque instance de la classe capsule que nous verrons en détail dans la deuxième partie, les capsules identifient leur types et le protocole qu’ils vont suivre pour leur transfert. Ensuite, quand une capsule arrive à un nœud, le code présent dans la capsule est vérifié avant d’être exécuté. Si le code exigé par le nœud n’est pas présent un “ load request ” ( une requête ) contenant le type de capsule et le type de protocole est envoyé au nœud précèdent. L’exécution de la capsule est alors suspendue en attendant le code pendant un temps fini. Quand un nœud reçoit un “ load request ” il répond immédiatement en envoyant un “ load response ” contenant le “ code group ”.

4. Programmer avec l’ANTS

Pour montrer comment utiliser l’architecture, nous allons monter deux simples protocoles introduisant le multicast et les services de mobilité dans un réseau ANTS.

Mobile Hosts :

Un protocole appelé Mobile est composé de deux types de capsules. Un type de capsule est envoyé par la station mobile qui contient des informations sur le mobile. Un second type de capsule est utilisé par les autres stations pour envoyé des messages à la station mobile.

La notion de “ home agent ” est utilisé pour signifier que c’est la localisation de base de la station mobile. Le “ foreign agent ” est l’adresse de destination du mobile.

Voici un exemple de code :

// En entrée :

// home = home agent

// next = nœud de destination

// forward = adresse de destination

// Chemin d’une capsule allant à foreign agent et ensuite à home agent

if (n.adress( ) != next)

{

n.routefornode(this, next) ;

return ;

}

// comment insérer une adresse de destination ?

n.put(src,MOBILE,new W_N(forward),IDLE) ;

// après être à foreign comment aller à home

if (n.adress( ) != home)

{

forward = next ;

next = home ;

n.routefornode(this,next) ;

}

Multicast :

Composé de deux types de capsules : un type pour qu’une capsule s’inscrive dans un groupe, les autres pour transporter le message multicast comme sur un réseau IP.

a) Implémentation d’un protocole

Pour implémenter un protocole, il faut l’écrire en Java et l’exécution se fait sur stations Linux. La distribution du code pour les protocoles de transfert utilise des classes préétablies qui sont contenues dans des fichiers.

Pourquoi l’ANTS a t-il choisi Java ? Parce qu’avant tout, c’est un langage d’un grand support pour la sécurité ( a travers les bytescodes et leur vérification ) et transportable sur n’importe quelle machine. Aussi parce que c’est un langage pré-compilé et offrant de bonnes performances à la compilation et à l’exécution. Il offre une grande flexibilité et supporte des liens et des chargements dynamiques, des multi–threads, et des librairies standard qui nous permettent de développer des protocoles dont le code est relativement court grâce à la notion d’objet.

Quand un nœud ANTS est lancé, il instancie automatiquement un objet Node et un objet Channel pour chaque interface du réseau.

Le nœud crée un thread pour entretenir le cache et accomplir d’autres tâches. Au lieu de lancer un thread par capsule qui ne favoriserait pas une haute performance du réseau, la plupart des traitements de capsules sont effectués séquentiellement en utilisant un thread par channel. Quand un paquet arrive sur la couche liaison, le thread du canal essaie de convertir le paquet en une instance de capsule de la classe approprié. Si le code nécessaire n’est pas présent dans le nœud, le paquet est stocké dans le cache du nœud jusqu’à que le code arrive en utilisant la distribution du code “ code distribution ”. Une fois qu’une capsule est instanciée, le thread lance la méthode evaluate en passant comme paramètre un nœud. Nous verrons plus en détail ce que fait la fonction evaluate.

Voici un tableau rappelant les différentes classes fondamentales et leurs méthodes respectives :

Classe

Méthodes

Node	address, get, put, routefornode, delivertoapp, send, receive, node
Channel	send, receive, node
Application	send, receive (upcall ), node
Capsule	evaluate, length, serialize, deserialize

La classe Node

Cette classe représente le runtime d’un nœud du réseau ; incluant son cache et son “ code distribution protocol ”.

La classe Channel

Cette classe fournit l’interface avec la couche liaison en connectant point à point les nœuds. Chaque Ethernet ou UDP “ tunnels ” pourrait être utilisé pour le transfert de capsules. De petits réseaux nécessiteraient un nœud par machine et connecteraient les nœuds entre eux par des canaux Ethernet. Pour de plus grands réseaux, plusieurs nœuds par machine et la connexion des nœuds se feraient par canaux UDP.

La classe Capsule

C’est une classe virtuelle qui peut crée des types de capsules comprenant certains protocoles.

La classe Application

Pour faire un programme qui puisse utiliser les services ANTS, il faut instancier une classe Application. Elle doit gérer les capsules, injecter les capsules dans le réseau et traiter les capsules arrivant du réseau.

b) Mesures de performance d’un réseau actif ANTS

Les tests ont été effectués sur un Pentium Pro 200 MHz, sur station Linux, à travers un réseau FastEthernet 100Mbps.

Capsule	Latence en ms	Nombre de capsules traitées par seconde
Data Mobile Multicast	3.1 3.2 4.2	160 150 130

Mesure de traitement d’un nœud

Capsule	Taille ( en octet )	Latence
Data Mobile Multicast	538 1625 1643	13.1 17.5 18.4

Mesure du “ code distribution ”

II. Description technique de l’ANTS

1. Généralités

La dernière version de l'ANTS est la version 1.2 (version utilisée dans notre projet), cette version est faite entièrement en langage JAVA 1.0.2. On trouve dans cette distribution de l’ANTS les répertoires suivants :

· ants : contient l’implémentation d’un nœud actif

· apps : c’est dans ce répertoire que l’on doit développer de nouvelles applications, y compris les capsules

· docs : contient des documents sur la version courante, ainsi que des guides d’utilisation

· runs : contient les fichiers de configuration du réseau, ces fichiers décrivent "l’architecture" du réseau actif (applications, nœud, protocoles…) ainsi que les tables de commutation des nœuds (sources, destinations, nœuds intermédiaires…), la configuration de ces fichiers et leur déploiement sur le réseau est donc indispensable pour développer de nouvelles applications.

· utils : contient des utilitaires pour développer des applications spécifiques

La famille de classes ping qui se trouve dans le répertoire apps fournit un exemple d’utilisation d’un réseau actif, avec une certaine configuration du réseau, cette configuration doit être changée certainement (adresse IP…) pour la mise en œuvre d’une nouvelle architecture.

Un réseau monté avec la plate-forme ANTS est manipulé par ses utilisateurs à l’aide de protocoles. De nouveaux protocoles, ainsi que des applications les utilisant, peuvent être développés par les utilisateurs en dérivant les classes virtuelles faites spécialement pour ce but. Ces nouveaux protocoles et applications sont ensuite utilisés en manipulant des instances de ces classes dérivées en conjonction avec le code d’ANTS ; un code ANTS fournit les services d’un réseau actif pour un seul nœud du réseau. Plus exactement :

• Un nouveau protocole est développé en dérivant la classe virtuelle "Protocol".
• Une nouvelle capsule ainsi que son code exécutable, est spécifiée en dérivant la classe virtuelle "Capsule". Rem : l’unité de données utilisée dans ANTS est appelée "capsule", une capsule contient les données ainsi que le code exécutable.
• Une nouvelle application est développée en dérivant le classe virtuelle "Application".
• Une instance de la classe Node représente un nœud actif du réseau.
• Un nouveau protocole et application sont utilisés en créant des instances de leurs classes et en les attachant au nœud. L’application est attachée au nœud afin de pouvoir envoyer et recevoir des capsules à travers le réseau. Le protocole est enregistré par le nœud afin que le réseau puisse obtenir son code lorsque c’est nécessaire.

2. Les classes principales

a) La capsule

Une capsule est une combinaison d’un paquet de données et de son code exécutable. Le code exécutable est exécuté sur chaque nœud traversé par la capsule à l’intérieur du réseau. Toute capsule hérite les méthodes suivantes, afin qu’elle puisse accéder aux champs de l’entête, ces fonctions font partie de la classe de base Capsule :

• getSrc() : retourne l’adresse de source de la capsule dans un entier "int" sur 32 bits. Cette adresse est envoyée implicitement par le nœud qui injecte la capsule dans le réseau, et n’est jamais changée. Un autre nœud interceptant cette capsule, vérifie le champ contenant l’adresse source, si cette dernière ne correspond pas à son adresse, il route cette capsule en se basant sur sa table de routage. La table de routage est contenue dans un fichier d’extension .routes et sera étudié en détails plus loin.
• getDst() : retourne l’adresse de destination de la capsule dans un entier "int" sur 32 bits. Sur un nœud non actif cette adresse est utilisée pour déterminer une route par défaut ; l’adresse spéciale 0.0.0.0 représente une adresse qui ne peut être utilisée pour router la capsule sans évaluer le contenu de la capsule.
• setDst() : positionne l’adresse de destination de la capsule.
• getPrevious() : retourne l’adresse du précédent nœud actif traversé par cette capsule.
• getType() : utilisée pour déterminer le type de la capsule.

• Les nouvelles classes dérivées de la classe Capsule, vont certainement rajouter d’autres champs à l’entête de la capsule selon les besoins de l’application. Elles doivent pour cela implémenter les méthodes suivantes, afin que le nœud puisse les manipuler :

• evaluate() : cette fonction est le cœur de la capsule, elle représente le code exécutable lui-même, elle est passée au nœud local comme un paramètre, pour être ensuite exécutée par ce nœud pour faire du traitement sur la capsule.
• encode() : initialise une représentation linéaire de la capsule.
• decode() : initialise une capsule à partir d'un buffer reçu du réseau.
• length() : détermine la longueur de la capsule initialisée pour le réseau.

Les méthodes d'encodage sont utilisées par le nœud pour transmettre et recevoir les capsules, en effet les capsules sont injectées et reçues par le réseau via le nœud local. A l'intérieur du réseau, cependant, la communication entre les nœuds nécessite que les capsules soient converties sous forme d'une séquence linéaire de bits, on a utilisé pour cela un Xdr (eXternal data representation). Rem : les classes dérivées, servant à développer de nouvelles applications doivent avoir un constructeur par défaut utilisé par le système pour les opérations d'encodage. Ce constructeur doit appeler celui de la classe de base en lui passant l'identifiant de la capsule, cet identifiant peut être initialisé en utilisant la fonction findId() fournie pour cet effet.

b) Le nœud actif

La classe Node implémente un seul nœud actif. Ce nœud exporte ses services aux :

• capsules : pour exécuter leur code et implicitement transférer leur code
• applications : pour enregistrer les protocoles et envoyer et recevoir les capsules sur le réseau.
• Node extensions : pour attacher et augmenter les services locaux du nœud.
• Les capsules accèdent au nœud par l'intermédiaire de leur fonction evaluate(), qui est passée comme référence au nœud. Parmi les services du nœud, on trouve :

• address() : récupère l'adresse du nœud local.
• routeForNode() : envoie une capsule vers un nœud donné en utilisant la table de routage.
• sendToNeighbors() : envoie une capsule vers tous les nœuds voisins.
• deliverToApp() : délivre une capsule à une application donnée.
• time() : renvoie l'heure courante.

Nombre d'autres fonctions figure aussi dans un nœud actif, parmi lesquelles on peut citer les fonctions servant à enregistrer les protocoles, celles servant à connecter les applications, et bien d'autres. Les particularités du langage Java participent au bon fonctionnement de ces fonctions.

La communication entre les paquets peut se passer via le cache, une capsule se met elle-même dans le cache dans l'attente d’être collectée. La synchronisation du java élimine la concurrence lorsque plusieurs paquets accèdent à l'entrée du même cache.

c) Le protocole

Les protocoles sont les unités par lesquelles le réseau est fabriqué. ils servent à réunir les capsules de même type pour une utilisation dans le réseau. Pour ce faire ils doivent diviser les capsules en code groups, où un code group consiste en le type de capsule. Chaque protocole doit fournir un constructeur par défaut qui groupe les capsules convenablement. Les méthodes suivantes sont héritées pour ce but :

· startProtocolDefn() : démarre le protocole.

· startGroupDefn() : démarre un nouveau code group.

· addCapsule() : ajoute un type de capsule au code group courant;

· endGroupDefn() : termine le code group courant.

· endProtocolDefn() : termine le protocole.

Une fois qu’un nouveau protocole est instancié, il doit être enregistré sur le nœud avant qu'une application puisse envoyer ou recevoir une de ses capsules, l'enregistrement doit être annulé à la fin de l'application. Les fonctions suivantes sur le nœud sont fournies pour cela :

· register() : enregistre le protocole sur le nœud

· unregister() : annule l'enregistrement du protocole.

d) l'application

Les applications sont les entités qui utilisent le réseau pour envoyer et recevoir des capsules aussi bien que pour faire tourner d'autres activités. La classe virtuelle Application de laquelle doivent dériver les nouvelles applications fournit l'accès au nœud et à ses services via les méthodes suivantes :

· send() : injecte une capsule dans le réseau via le nœud local.

· receive() : extrait une capsule du réseau via le nœud local.

· thisNode() : retourne une référence au nœud courant.

· port() : retourne le port sur lequel l'application est connectée sur le nœud local. Les ports sont utilisés pour l'adressage des applications et sont identiques aux ports TCP/UDP. Une application supporte un seul port.

La fonction attachApplication() d'un nœud actif connecte une application au nœud sur un port spécifié.

3. La configuration

La mise en œuvre d'un réseau actif nécessite qu'une topologie du réseau soit mise en place. ANTS fournit des outils pour réaliser ce processus.

En effet, toutes les configurations du réseau, ainsi que les adresses des nœuds, les applications et les paramètres d'initialisation sont spécifié dans des fichiers simples de format texte. Le fichier makeroutes analyse ces fichiers pour en fabriquer les routes (path) entre tous les nœuds. ANTS utilise donc des tables de routage statique et "non connecté".

La classe ConfigurationManager peut lire ces fichiers et démarrer un de leurs nœuds localement. Ceci implique la création d'applications, et d'extensions et de les connecter aux autres et de démarrer leurs opérations. Pour ce faire, toutes ces entités sont dérivées de la classe de base ManagedObject, et possèdent ces fonctions suivantes :

· setArgs() : utilisée pour opérer sur les arguments de la ligne de commande.

· start() : est appelée par le système lorsque toutes les entités sont connectées et prêtes à commencer les opérations.

Les entités peuvent aussi accumuler des messages informationnels, des warning ainsi que des messages d'erreurs.

III. Mise en œuvre

1. Préliminaires

a) Configuration du réseau

Pour utiliser la plate-forme ANTS il nous faut reproduire une architecture réseau. Nous disposons de 2 machines Linux possédant chacune 2 cartes Ethernet. Nous allons ainsi pouvoir reproduire le comportement d’un réseau local à 4 postes.

Les adresses choisies pour les tests sont des adresses brûlées du type 192.168.1.xxx.

Les cartes Ethernet sont des 3com Etherlink 3C905 que nous avons installé en téléchargeant les drivers sur le site de 3com. Nous avons ensuite configuré Linux pour qu’il utilise les deux cartes. Pour ce faire par l’intermédiaire de linuxconf nous avons activé les 2 premiers adaptateurs réseaux en utilisant les interfaces eth0 et eth1.

Nous avons ensuite connecté les 4 cartes Ethernet sur un HUB et vérifié le bon fonctionnement du réseau.

Architecture réelle

Architecture émulée

b) Installation logicielle

Les fichiers de l’ANTS se présentent sous la forme d’un fichier compressé ants-release-11-2-97.tar.gz. Ce fichier, une fois décompressé par la commande tar –xvzf nom_fichier génère un répertoire ants-1.2.

La plate-forme ANTS étant écrite en JAVA, il est nécessaire d’installer un compilateur JAVA. Nous avons choisi d’installer la jdk 1.1.5 en téléchargeant le fichier jdk-1.1.5-5.i386.rpm et en l’installant avec la commande rpm –ivh nom_fichier. La dernière étape préliminaire consiste à indiquer au compilateur Java le chemin des classes de l’ANTS à compiler. Pour ce faire, nous avons ajouté la ligne suivante dans le fichier /etc/bashrc :

CLASSPATH=$CLASSPATH:/antsfile/ants1-2

2. Utilisation de la plate-forme

a) Arborescence

ants-1.2		Répertoire d’installation
	Ants	Sources Java de l’ANTS
	Apps	Sources Java des applications de démonstration
	Auction	Pas utilisé
	Docs	Documentation
	Runs	Répertoire de lancement des applications
	Tmp	Répertoire temporaire
	Utils	Sources Java des classes “ utilitaires ”

Il est important de ne pas modifier cette arborescence car elle est nécessaire au Makefile pour pouvoir compiler correctement toutes les sources.

b) Compilation

A l’installation, les fichiers fournis sont des sources Java qu’il faut compiler. Pour ce faire, il suffit de se placer dans le répertoire d’installation et de taper la commande make. Cette commande à pour but d’exécuter le script contenu dans le fichier Makefile se situant dans le répertoire courant. Ce script va descendre dans chacun des sous répertoire en compilant toutes les sources, et en mettant à jour tous les fichiers de configuration.

Chaque sous répertoire atteint contient un fichier Makefile qui sera appelé par le Makefile du répertoire source.

Une fois cette commande terminée, si l’installation de Jdk à été effectuée correctement et si la variable d’environnement $CLASSPATH est correctement positionnée, la plate-forme ANTS est prête à fonctionner.

c) Fichiers de configuration

Nous allons ici nous intéresser particulièrement au répertoire runs. C’est à partir de ce répertoire que sont lancées toutes les applications. A l’installation, une commande ls dans ce répertoire donne le résultat suivant  :

Makefile auction.config data.config mobile.config ping.config

README.html auction.start join.config mobile.start ping.start

abone.config auction_filter.config join.start multicast.config vote.config

abone.start* auction_filter.start makeroutes* multicast.start vote.start

On remarque une certaine nomenclature dans l’appellation des fichiers :

nom_application.start

nom_application.config

Ces deux fichiers ont une importance capitale dans le lancement d’une application ou d’un nœud du réseau. Nous allons décrire leur importance fonctionnelle, puis nous étudierons leurs syntaxes.

· nom_application.start : script contenant les lignes utilisées pour lancer la configuration du réseau. Chaque ligne correspond à un nœud du réseau.

· nom_application.config : description du réseau, des différents nœuds, applications s’y trouvant.

De plus, il existe un troisième fichier de configuration : nom_application.routes. Ce fichier est générer automatiquement lors du lancement de la commande make. C’est la table de routage du réseau créée à partir de sa description effectuée dans le .config.

Syntaxe des fichiers de configuration

.start

java ants.ConfigurationManager nom_application.config IP_machine1 >& nom_fichier_log1 &

java ants.ConfigurationManager nom_application.config IP_machine2 >& nom_fichier_log2 &

java ants.ConfigurationManager nom_application.config IP_machine3 >& nom_fichier_log3 &

…

ConfigurationManager est la routine java chargée d’analyser un fichier .config afin de lancer différents éléments du réseau.

Chacune de ces lignes lance pour la machine IP_machine_x les éléments réseau définis dans le fichier nom_application.config en utilisant le fichier log nom_fichier_logx.

On remarque que le .config est commun au lancement de toutes les machines.

.config

node IP_machine1 –routes nom_application.routes –log 255

channel IP_machine1 num_port_UDP –log 255

application IP_machine1 apps.Nom_application [paramètres]

manager IP_machine1 –gui true –log 255

node IP_machine2 –routes nom_application.routes –log 255

channel IP_machine2 num_port_UDP –log 255

application IP_machine2 apps.Nom_application [paramètres]

manager IP_machine2 –gui true –log 255

…

connect IP_machine1 IP_machine2

connect IP_machine2 IP_machine3

connect IP_machine3 IP_machine4

…

Analyse des lignes du fichier .start :

Toutes les lignes se terminant par –log 255 indique un fonctionnement des programmes avec un niveau de log 255. Cette valeur indique la précision de ce qui sera logué.

· node IP_machine1 –routes nom_application.routes –log 255

Lancement d’un nœud du réseau sur la machine IP_machine1 en utilisant la table de routage contenue dans le fichier nom_application.routes.

· channel IP_machine2 num_port_UDP –log 255

Création d’un tunnel de communication pour la machine1 en utilisant le port UDP num_port_UDP.

· application IP_machine1 apps.Nom_application [paramètres]

Lancement de l’application Nom_application contenue dans le package apps avec paramètres d’exécution.

· manager IP_machine1 –gui true –log 255

Lancement du manager, indispensable à l’ANTS pour faire notamment la liaison avec l’interface graphique.

· connect IP_machine1 IP_machine2

connect IP_machine2 IP_machine3

connect IP_machine3 IP_machine4

Ces lignes décrivent l’architecture du réseau et ne servent qu’à générer la table de routage (table générée lors de l’exécution de la commande make à partir du répertoire runs.

On remarque que ce fichier .config contient une description de tous les nœuds et de toutes les applications lancés sur le réseau. C’est le numéro de machine contenu dans les lignes du .start qui fera que le ConfigurationManager ira chercher dans le .config seulement les lignes le concernant.

Par exemple, lors de l’exécution de la première ligne du .start de l’exemple :

java ants.ConfigurationManager nom_application.config IP_machine1 >& nom_fichier_log1 &

seules les lignes suivantes du .config sont prise en compte :

node IP_machine1 –routes nom_application.routes –log 255

channel IP_machine1 num_port_UDP –log 255

application IP_machine1 apps.Nom_application [paramètres]

manager IP_machine1 –gui true –log 255

les autres lignes ne sont pas lues.

Méthode de création des fichiers de configurations :

De façon à simplifier les choses, une méthode d’écriture des fichiers de configurations est préconisée.

i) écriture d’un .config commun à tout le réseau, décrivant tous les éléments du réseau lancés sur toutes les machines.

ii) écriture d’un .start pour chaque machine du réseau qui ne lancera que les éléments de la machine concernée.

iii) lancement du make qui par l’intermédiaire du script makeroutes et à partir des données contenues dans le .config va générer la table de routage (le .routes).

3. exemples applications

D’une manière générale, une application supportée par l’ANTS est une classe java dérivée de la classe ants.Application utilisant un protocole particulier et donc une capsule (paquet de données) spécifique.

Nous allons ici étudier des exemples d’applications en analysant à la fois leurs fichiers de configurations et le code java spécifique.

a) PingApplication

Cette application est fournie en exemple avec l’ANTS. Elle illustre l’utilisation de l’ANTS en implémentant le protocole ping dans un réseau de 3 machines émulée par une seule.

La force des réseaux actifs passe par le fait que le protocole ping va être implémenté dynamiquement par l’intermédiaire de la définition d’une capsule Ping, et du protocole associé.

Les fichiers spécifiques à cette application sont :

runs/ping.start script de lancement sur la machine

runs/ping.config fichier de configuration décrivant l’architecture réseau

runs/ping.routes table de routage générée par makeroutes

apps/PingApplication.java source de l’application

apps/PingProtocol.java source de l’implémentation du protocole Ping

apps.PingCapsule.java source de l’implémentation des capsules Ping

Telle que l’exemple a été préparé, les 3 adresses virtuelles des machines sont :

18.31.12.1/2/3.

Analyse des fichiers de configuration :

ping.start

#!/bin/csh

java ants.ConfigurationManager ping.config 18.31.12.3 >& 18.31.12.3.log &

java ants.ConfigurationManager ping.config 18.31.12.2 >& 18.31.12.2.log &

java ants.ConfigurationManager ping.config 18.31.12.1

kill %?18.31.12.3

kill %?18.31.12.2

Lancement de trois machines configurées avec le fichier ping.config.

ping.config

node 18.31.12.1 -routes ping.routes -log 255

channel 18.31.12.1 localhost:8001 -log 255

application 18.31.12.1 apps.PingApplication -target 18.31.12.3

manager 18.31.12.1 -gui true -log 255

node 18.31.12.2 -routes ping.routes -log 255

channel 18.31.12.2 localhost:8002 -log 255

manager 18.31.12.2 -gui true -log 255

node 18.31.12.3 -routes ping.routes -log 255

channel 18.31.12.3 localhost:8003 -log 255

manager 18.31.12.3 -gui true -log 255

connect 18.31.12.1 18.31.12.2

connect 18.31.12.2 18.31.12.3

Configurations des 3 machines :

· 18.31.12.1

Lancement d’un nœud, d’un channel, d’un manager et de notre application.

L’application PingApplication tournera donc sur la machine 18.31.12.1 avec comme cible la machine 18.31.12.3.

· 18.31.12.2/18.31.12.3

Lancement uniquement d’un nœud, channel et manager.

Analyse des sources java :

· PingApplication.java

L’application, après avoir déclaré le protocole utilisé par l’intermédiaire de la ligne

thisNode().register(new PingProtocol()) ;

envoi une capsule PingCapsule à la machine 18.31.12.3.

En parallèle, grâce à un Thread, l’application attend la réception d’une PingCapsule. A réception, l’application par l’intermédiaire de la fonction receive() détermine le traitement à effectuer (ici calcul du temps de trajet+affichage).

· PingCapsule

La méthode la plus importante est evaluate(). Cette méthode va définir le traitement de la capsule à effectuer lors de la réception par un nœud. Ce code est naturellement déployé dynamiquement sur le réseau, de proche en proche, en commençant par le nœud ou l’application tourne.

Méthode evaluate()

public boolean evaluate(Node n) {

if ( n.getAddress() == getDst()) {

ping = true;

}

else if (ping!=true) {

return n.routeForNode(this, getDst());

}

if (n.getAddress() == getSrc()) {

return n.deliverToApp(this, dpt);

} else if (ping) {

return n.routeForNode(this, getSrc());

}

return false;

}

La variable ping est un booléen, données membres de la classe PingCapsule. Elle sert à déterminer si la cible a déjà été atteinte ou pas. La manière dont le protocole ping est implémenté est donc la suivante :

· Tant que la cible n’a pas été atteinte, route la capsule vers la cible

· Dès que la cible à été atteinte, route vers la source

· Dès que la capsule est revenue à la source, délivre la à l’application

· PingProtocol

Cette classe n’implémente qu’une seule procédure, le constructeur de classe PingProtocol() qui à pour but de déclarer le type de capsule PingCapsule au sein du nœud courant.

Constructeur de PingProtocol

public class PingProtocol extends Protocol {

public PingProtocol() throws Exception {

startProtocolDefn();

startGroupDefn();

addCapsule("apps.PingCapsule");

endGroupDefn();

endProtocolDefn();

}

b) myPingApplication

Après avoir réussi à faire fonctionner l’exemple précédent, notre premier test a été de faire fonctionner cet exemple sur un véritable réseau ANTS et non pas sur une émulation.

La difficulté a été de réécrire le fichier .config, et les n fichiers .start (un par machine).

Les sources ont été inchangées, si ce n’est le nom des classes auxquels nous avons systématiquement rajouté un “ my ”.

Nous avons créé un réseau actif suivant l’architecture suivante :

Voici les fichiers de configurations que nous avons écrit :

Fichier myping.config

node 192.168.1.1 -routes myping.routes -log 255

channel 192.168.1.1 192.168.1.1:8001 -log 255

application 192.168.1.1 apps.PingApplication -target 192.168.1.4

manager 192.168.1.1 -gui true -log 255

node 192.168.1.2 -routes myping.routes -log 255

channel 192.168.1.2 192.168.1.2:8002 -log 255

manager 192.168.1.2 -gui true -log 255

node 192.168.1.3 -routes myping.routes -log 255

channel 192.168.1.3 192.168.1.3:8003 -log 255

manager 192.168.1.3 -gui true -log 255

node 192.168.1.4 -routes myping.routes -log 255

channel 192.168.1.4 192.168.1.4:8004 -log 255

manager 192.168.1.4 -gui true -log 255

# description de l’architecture du réseau

connect 192.168.1.1 192.168.1.2

connect 192.168.1.2 192.168.1.3

connect 192.168.1.3 192.168.1.4

Fichier myping.start pour machine 1

java ants.configurationManager myping.config 192.168.1.1

java ants.ConfigurationManager myping.config 192.168.1.2 >& fich.log &

Fichier myping.start pour machine 2

java ants.ConfigurationManager myping.config 192.168.1.3 >& fich3.log &

java ants.ConfigurationManager myping.config 192.168.1.4 >& fich4.log &

Ainsi, en lançant les fichiers myping.start sur leurs machines respectives, on parvient à lancer :

· 2 nœuds réseau + l’application sur la machine 1

· 2 nœuds réseau sur la machine 2

Evidemment, il faut générer la table de routage myping.routes en exécutant la commande make qui appellera le script makeroutes.

En cliquant, su le bouton de l’application sur la machine1, on réussit bien à pinger la machine 192.168.1.4 en traversant bien tout le réseau, c’est à dire successivement les machines :

192.168.1.1 -> 192.168.1.5 -> 192.168.1.2 -> 192.168.1.4

puis

192.168.1.4 -> 192.168.1.2 -> 192.168.1.5 ->192.168.1.1 -> Application

a. Ftp

Pour des raisons de temps, nous ne détaillerons pas ici les listings de ce programme mais une démonstration sera faite lors de la soutenance.

Principe :

Notre but été d’implémenter sur le réseau un protocole de transfert de fichier utilisé par 2 applications tournant sur 2 machines différentes du réseau.

Les 2 applications sont : ftpServeur et ftpClient.

Pour ce faire, nous avons du réécrire les fichiers de configurations, développer 2 applications en Java, et écrire le protocole de transmission ftpCapsule.java.