Communication entre agents mobiles

Il est essentiel que les agents mobiles puissent avoir un moyen de communiquer entre eux ou avec l’extérieur, sans avoir à se préoccuper de leur localisation. Les plates-formes évoquées au début de ce chapitre, sont reprises ici en fonction des moyens de communication qui sont fournis aux agents mobiles.

– MIAMI : Une définition d’une boite aux lettres sert de moyen de récep-tion des communicarécep-tions entre les agents mobiles s’envoyant des messages ayant pour adresse : nom@domaine. Domaine est le domaine où se situe actuellement l’agent destinataire du message. L’agent mobile ne changeant pas forcément de domaine lors de la migration. Les agents mobiles peuvent tout de même se localiser entre eux, puisque les facilités requises par MASIF [14] en terme de localisation des agents mobiles (service d’enregistrement utilisant le Bus Corba, RMI, etc..), sont implémentées en standard dans la plate-forme Grasshopper.

void run() { // starting method for every Agent

// Asking to AgentSystem the list of Nodes in this Domain Node = AgentSystem.getAllDomain();

CurrNode=0;

// Looking for the first active Node for (;CurrNode<Node.length;CurrNode++)

if (AgentSystem.isActive(Node.Name)) goNode(); .. // Error: no active nodes

}

void goNode() { try {

this.go(Node[CurrNode].Name,"VerifyNode"); }

catch(Exception e) { //Can’t go, System or Security exception ... goHome(); // Back home with failure status

} }

void verifyNode() { // Restart method specified by goNode() try {

CPUload[CurrNode]=Monitor.getCPULoad(); }

catch(Exception e) { // action not allowed ... // Actions for exception handling } CurrNode++; for (;CurrNode<Node.length;CurrNode++) if (AgentSystem.isActive(Node.Name)) goNode(); goHome(); }

Fig. 3.5 – Classe d’un agent mobile dans SOMA

– MAP : les messages sont échangés en connaissant le lieu et le port TCP du MAP Server (nœud de la plate-forme), et si l’agent n’est pas sur le nœud, alors le message n’est pas réacheminé. Le système utilise une liste des MAP Servers pour essayer de localiser l’agent. En cas d’échec, le message ne peut pas être retransmis.

– MAGENTA : Lorsque deux agents ont besoin de communiquer, ils se fixent un rendez-vous sur le même site, et s’échangent des messages pour com-muniquer. Lorsque la station d’administration veut communiquer avec les agents mobiles elle utilise un service de localisation inclues dans la plate-forme.

– SOMA : Dans le cadre de cette plate-forme, les agents mobiles s’échangent des messages pour communiquer entre eux. Pour se localiser dans le domaine de SOMA, un agent mobile utilise les facilités offertes par MAFFinder [14], une sorte de service d’enregistrement que les agents mobiles interrogent afin de pouvoir se localiser. Chacun des nœuds de la plate-forme enregistrant au fur et à mesure les agents mobiles qu’ils hébergent.

s’enregistrent afin de pouvoir communiquer entre eux. Une autre méthode pour fournir des communications entre les agents mobiles et d’utiliser le nœud maître de la plate-forme qui possède la liste de tous les agents mo-biles en activité dans la plate-forme. Par ce biais, un agent mobile localise indirectement l’agent mobile avec lequel il souhaite communiquer.

– MobileSpace : Chaque agent maintient une file de requêtes de messages et il s’enregistre auprès des autres agents avec lesquels il doit converser (donc défini statiquement). Lorsqu’un agent doit bouger, il laisse derriere lui un agent forwarder, qui permet à tous autres agents mobiles visitant le nœud, de savoir le recontacter par le bias des forwarders. Ces agents mobiles utiliseront le forwarder agent pour migrer à la même localisation que l’agent mobile avec lequel ils doivent communiquer, et pourront ensuite dialoguer avec lui.

Les mécanismes de localisation et de communication entre les agents mobiles doivent être transparents aux agents mobiles et c’est le rôle de la plate-forme de fournir de tels mécanismes. Comme nous verrons par la suite, la plate-forme ProActive a le mérite de fournir ces mécanismes de manière que l’on peut qualifier d’idéale !

3.2.6 Accès aux données de la MIB SNMP

Afin de pouvoir accéder aux informations de la MIB SNMP, il est utile que les agents mobiles puissent converser avec les agents SNMP.

Certaines plates-formes ont intégré dans leur distribution des classes permet-tant de converser en SNMP. Cela implique que lorsqu’un agent mobile arrive sur un nœud sur lequel il doit exécuter une fonction d’administration requérant le protocole SNMP, il n’a pas besoin de télécharger les classes. Ces classes mettent en œuvre une API qui, pour masquer la complexité de l’utilisation du proto-cole SNMP, prédéfinit un ensemble de fonctions d’administration (par exemple, l’obtention de statistiques sur des interfaces réseaux). L’inconvénient évident est que certaines requêtes SNMP ne pourront pas être réalisées. Cette solution est mise en œuvre, par exemple par SOMA [10], qui intègre une interface (nommée

Monitoring Application Programming Interface), permettant de fournir une

agré-gation des résultats des indicateurs de surveillance. Ainsi l’agent mobile arrive et collecte directement la ou les valeurs des indicateurs.

Une autre méthode est celle qui consiste à associer le code de l’agent mobile avec une API indépendante de la plate-forme qui donne accès à toute la pile du protocole SNMP (méthodes, fonctions, encodages, décodages, etc..), comme par exemple AdventNet [2]. En utilisant cette technique, l’agent mobile est libre d’accéder à n’importe quelle information contenue dans la MIB de l’agent SNMP. L’agent mobile va devoir télécharger les classes utiles pour réaliser sa fonction d’administration SNMP, ce qui peut être pénalisant en terme de performance si le lien réseau entre l’hôte de départ et l’hôte d’arrivée est de faible débit.

3.3 Itinéraires