WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Intégration de protocoles de sécurité pour la communication inter-agents dans la plate-forme Aglets

( Télécharger le fichier original )
par Manel Sekma
Institut Supérieur d'Informatique et de Mathématiques de Monastir - Maitrise 2007
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

2.3 Agent stationnaire vs Agent mobile

Notons bien que l'agent stationnaire s'exécute seulement sur la machine où il est créé. Si jamais il a besoin d'informations supplémentaires inexistantes localement ou d'interagir avec

d'autres agents dans différents systèmes, alors il utilise typiquement le mécanisme RPC (Remote Procedure Calling) qui est une méthode appliquée dans le modèle client serveur.

Par contre, Un agent mobile est un processus autonome contenant du code et des données, capables de se déplacer d'une machine à une autre afin de réaliser une tâche précise. Ce code représente l'ensemble des instructions du programme, et les données sont constituées soit du véritable contexte d'exécution du programme, soit de variables émulant ce contexte. Un contexte d'exécution est composé de la pile de récursivité, du tas et des registres. Ce contexte évolue au cours de la vie de l'agent.

Le choix d'employer des agents stationnaires ou mobiles dans un système, dépend non seulement de la nature technique et conceptuelle de l'agent mais aussi du contexte où il est prévu d'être employé.

Dans le cas d'un système à agents stationnaires, on se pose qu'un agent veut accéder à une base de données distante, dans ce cas l'interaction avec la base se fait à travers le réseau comme il est indiqué dans la figure 1.1.

Utilisateur A

Site A

Agent A

Site B

BD

Figure 1.1 : Interaction à travers le réseau.

Autrement, dans le cas des agents mobiles, supposons que l'utilisateur A veuille récupérer des informations sur un certain sujet. En interagissant avec son agent personnel, la requête est formellement spécifiée. Ceci est illustré par la figure1.2.

Site A

Utilisateur A

Agent A

Site B

BD

Figure 1.2 Migration (phase 1).

Puis, comme le montre la figure 1.3, l'agent migre du site A au site B sur laquelle se trouve une base de données contenant les informations recherchées.

Site A

Site B

Utilisateur A

Agent A

Agent A

BD

Figure 1.3 Migration (phase 2).

Ensuite, La figure1.4 montre l'agent interagissant avec la base de données du site distant pour récupérer les données recherchées.

Figure 1.4 Migration (phase 3).

Utilisateur A

Site A

Agent A

Site B

BD

Puis, une fois l'agent satisfait, il retourne vers le site d'origine. Ceci est illustré par la figure1.5.

Utilisateur A

Site A

Agent A

Agent A

Site B

BD

Figure 1.5 Migration (phase 4).

Finalement, comme le montre la figure1.6, l'agent rapporte - d'une manière interactive - les résultats à son utilisateur.

Site A

Utilisateur A

Agent A

Site B

BD

Figure 1.6 Migration (phase 5).

Dans le plus part des applications, les systèmes à agents mobiles semblent être plus efficaces que les systèmes classiques à agents stationnaires, car dans un système informatique, les interactions intra-site sont moins coûteuses que les interactions inter-sites, mais ceci n'est pas toujours vrai, car on peut avoir une négociation entre agents statiques et même entre agents mobiles dans un système et aussi lorsque il s'agit du coût de migration, etc.

Prenons un exemple explicatif sur les deux approches à agents mobiles et à agents statiques.

Dans la première phase de l'approche « agents mobiles » de cet exemple, l'utilisateur et l'agent établissent la requête. Supposons qu'elle ait une taille de r octets. Puis l'agent migre vers le site B. Supposons que la taille de l'agent soit fixe à a octets. L'agent interagit avec la base de données dont la taille est de b octets. Finalement, l'agent rentre pour communiquer la solution composée de s octets. Donc, la quantité totale de données transférées entre les sites différents est (a + r) + (a + s) octets. Notons qu'il n'est pas toujours nécessaire qu'un agent retourne chez son utilisateur et que - souvent - il suffit qu'il envoie le résultat. Toutefois, en général, on suppose que l'agent rentre.

Par contre dans l'approche classique de cet exemple, utilisant un agent statique, la quantité totale de données transférées peut monter jusqu'à r + b octets. En effet, dans le pire des cas, on demande le transfert de la base complète et on la traite localement.

Comparons les deux approches, en supposant que r est négligeable. Le graphique 1 (Figure 1.7) montre le nombre d'octets transférés, dans les deux approches, pour b = 100000, a = 5000

et s / b entre 0et 1. Le graphique 2 visualise la même relation, mais pour a = 25000 (Figure 1.8).

Figure 1.7 Graphique1 : Agents statiques vs. agents mobiles (a = 5000)

Figure 1.8 Graphique 2 : Agents statiques vs. agents mobiles (a = 25000).

Donc, et comme le montrent les deux graphiques, l'application des agents mobiles n'est pas toujours avantageuse. Surtout lorsque les tailles des agents et des solutions (relatives à la base de données) sont grandes, l'approche classique est préférable. Cependant, en général, la taille des agents et le ratio s / b sont modestes, et la mobilité prometteuse.

Par contre, ce raisonnement n'est valide que si la requête ne peut pas être formulée d'une

telle manière qu'elle peut être traitée directement pas le système de gestion de la base de données. Dans ce cas, il suffit d'envoyer la requête et de recevoir la solution sans impliquer des agents. Cette solution est toujours la plus économique car seulement r + s octets doivent être transférés. Donc, cette application très étudiée des agents mobiles n'apporte aucun avantage si les requêtes peuvent être normalisées pour les bases de données impliquées. Ceci est sans doute une des raisons principales pour laquelle les agents mobiles ne sont pas encore utilisés à une échelle importante ainsi que les agents statiques sont encore employés par les développeurs dans ce domaine.

Toutefois, dans un monde informatique de plus en plus sophistiqué et personnalisé, nous pouvons nous attendre à une croissance importante de requête non standard. De plus, il est possible que certains utilisateurs préféreront envoyer leurs agents personnels plutôt que faire confiance au système de gestion distant, en estimant - par exemple - que leurs agents sont plus fiables.

Pour cette raison, les chercheurs sont dirigés vers le développement des applications en intervenant des agents coopératifs stationnaires et mobiles, dont leurs tâches sont définies après avoir calculé les performances en fonction des besoins de l'application.

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy