Bonjour a tous,
 
Je realise en ce moment un systeme d'agents mobiles.
Chaque agent est une thread, je pensais faire passer mes threads entre les sites d'acceuil en les serialisants.
 
Je me pose 2 questions :  
 
- Dans quel etat sera ma thread lorsque je la de-serializerais ?!
Java ne permettant pas d'embarquer la pile d'execution, la thread ne sera pas surement pile poil dans son etat avant transfert mais alors ou en sera-elle cette p'tite chose ?  
 
- Aurais-je besoin d'avoir les fichiers .class source de mes agents pour redemarrer ma thread (sur son nouveau site).
 
Merci d'avance !

sérialiser des threads?    
 
 

bon je n'ai pas de notion théorique d'agent mobile meme si ca m'intéresse fortement. Il devrait y avoir l'un ou l'autre pattern pour ce genre de cas.
 
Cela dit, je pense qu'il y a un prob de comprhénsion. Ce que tu souhaites sérialiser c'est l'état de ton agent n'est ce pas?
 
Bon imagines un travailleur à la chaine. Tu voudrais bien déplacer ce travailleur sur une autre chaine. Bon qu'est ce que tu déplaces? Le travailleur ou la chaine?
 
Bin le travailleur. Donc c'est ton agent mobile que tu déplaces et que tu fais refonctionner dans une nouvelle thread.
 
Est ce clair?

tu as aglets d'ibm japon
 
http://sourceforge.net/projects/aglets/
 
un article
 
http://www.javaworld.com/javaworld [...] -hood.html
 
 
 

Taureau >>> Est ce que ce que j'ai écrit dans mon post est stupide ou bien est ce correct?

non c exact  ...
 
la preuve il est dit la meme chose que toi là http://www.javaworld.com/javaworld [...] od-p2.html  
 
mais tu le dis avec des mots mieux    
 

[/mode nostalgie on]
 
Cà me rappelle les questions de lemmy pendant les cours de JC, pas toi Benou ?
 
[/mode nostalgie off]
 
Copyrights Lemmy-"Et si on parlais d'introspection ?"®

 
Oui, c'est deja plus clair. Mon probleme c'est que j'avais mal compris le principe de la serialization.
 
Pour moi on serialise, on passe ca tout ca dans le socket et pouf a la sortie lapin blanc on a un object   ......
 
Bon ok, je suis pas drôle.....maintenant j'ai compris que j'aurais bien besoin de mes fichiers .class et egalement d'un class-loader.
 
Mais il y a encore une chose sur laquel je m'interroge :
 
Mon agent est une thread ( il etend la class "Thread" ), je vais donc devoir serialiser cette thread pour consever en quelque sorte sont etat ( c'est ce que j'entendais par "serialiser une thread" ). Quand je vais de-serialiser, je vais devoir refaire un "start" sur ma thread ou pas ?!
 
Concernant "aglet", c'est un projet scolaire (fac) tout le code on devra l'avoir pondu nous meme, a l'exception du parsing XML et du classloader(j'espere utiliser URLClassLoader)....
Donc j'oublie ( du moins pour ma realisation car l'article est tres interessant, merci Taureau).
 
 
En tout ca, merci pour vos reponses.

ton agent mobile ne doit pas étendre runnable ni thread. De plus une thread n'a qu'un et un seul cycle de vie. Tu la crées et tu appelles start dessus. une fois qu'il sort de cette méthode d'une manière ou d'une autre c'est terminé. Tu ne peux plus appeler start.

Meliok a écrit a écrit :   Cà me rappelle les questions de lemmy pendant les cours de JC, pas toi Benou ?

c'est vrai qu'il y a un peu de ca !

Bonjour,
 
En fait je te conseille d'avoir des threads identiques sur toutes les machines sur lesquelles ton agent peut s'exécuter. Ensuite, il faut que ton thread soit juste un flux d'exécution : il appelle la méthode doIt() (par exemple) de ton objet Agent. Et c'est ton agent que tu sérializes (avec son état) et que tu envoies sur une autre machine. Là un autre thread le récupère et appelle de nouveau la méthode doIt() de cet agent. Tu ne fais donc pas voyager tes threads mais seulement tes agents avec leur état.

 
Salut,
 
Que fais tu exactement ? Dans quel cadre ? Je bosse sur une plateforme agent Java : Lana (bientot openlana vu qu'on la passe en open source d'ici la fin de l'annee si les delais sont respectes).
 
J'ai developpe cette plateforme dans le groupe de recherche ou je bosse et on continue a la faire evoluer. Si tu as des questions particuliere, si tu veux lire l'article qu'on a ecrit sur le sujet et presente a ECOOP 2002 ou plus precisement avoir plus d'infos sur Lana (puis eventuellement participer au projet par la suite) fais moi signe, je serai heureux de discuter avec toi.
 
Ciao !

moi ca m'intéresse ton article. Tu as un lien?

 
Voila l'url :
 
http://www.pawlak.ch/articles/lana.pdf
 
Si niveau developpement la plateforme a beaucoup evolue (concretement, la plateforme existe en tant qu'API Java, ainsi que sous la forme d'une mini VM modulaire), les motivations et l'approche restent les memes.  
 
Bref, le peu d'APIs que vous trouverez dans l'article a completement ete revu. Ce qui reste interessant ce sont les notions d'autonomie qui sont indispensables dans le cadre de reseaux ad hoc.  
 
J'aurais change pas mal de passages apres coup mais bon... L'article a ete publie dans cet etat et on a deja passe suffisemment de temps dessus.
 
A+

phenixl,
 
Ce que je cherche a faire, c'est mettre un place un ensemble de serveur sur lequel pourront migrer mes agents, être charger dynamiquement puis reprendre leur activité.
 
C'est un projet dans le cadre de l'université, c'est un travail qui me vaudra une note et surement beaucoup de nouvelles connaissances.
 
Etant donné que je ne dispose que de 3 semaines pour le faire (on nous accorde 1h30 / semaines mais je vais faire des heures supplementaires) ce sera quelque chose de simple:
 
Les serveurs d'acceuil dispose d'un Name Service, qui repertorie où sont les agents et quels sont les serveurs dispo.
Les agents sont des threads, que je serialize pour consever l'etat. J'envoie ensuite le jar, le serveur d'acceuil doit le charger dynmiquement ( classloader == Ouinnnnnnn     pour le moment).
 
Et pour le moment c'est le niveau que je me suis fixé ce serait deja pas mal si j'arrive a ca.
 
Voila c'est tout
 
A bientot  

ben ca me parait super complexe à partir du moment ou tu arrive à encoder (sauvegarde) l'état d'un agent.
 
Par contre, le fait que l'agent SOIT un thread je trouve ca bizarre ...
 
Et c'est quoi le problème que tu te poses avec le classloader ? a priori, tu n'as pas besoin de charger des nouvelles classes dynamiquement ... à moins que tes agents puissent utiliser des classes que ton serveur ne connait pas, mais dans ce cas là tu as oublié de nous le dire et ca complique pas mal les choses ...

bartleby a écrit a écrit : phenixl,   Ce que je cherche a faire, c'est mettre un place un ensemble de serveur sur lequel pourront migrer mes agents, être charger dynamiquement puis reprendre leur activité.   C'est un projet dans le cadre de l'université, c'est un travail qui me vaudra une note et surement beaucoup de nouvelles connaissances.   Etant donné que je ne dispose que de 3 semaines pour le faire (on nous accorde 1h30 / semaines mais je vais faire des heures supplementaires) ce sera quelque chose de simple:   Les serveurs d'acceuil dispose d'un Name Service, qui repertorie où sont les agents et quels sont les serveurs dispo. Les agents sont des threads, que je serialize pour consever l'etat. J'envoie ensuite le jar, le serveur d'acceuil doit le charger dynmiquement ( classloader == Ouinnnnnnn     pour le moment).   Et pour le moment c'est le niveau que je me suis fixé ce serait deja pas mal si j'arrive a ca.   Voila c'est tout   A bientot

 
Sans vouloir te decourager (loin de moi cette idee) 4h30 pour creer une plateforme agents c'est infaisable... Avec une spec tu peux eventuellement faire un truc hyper basique (et encore...)
 
Pour la migration, ce que tu dois faire c'est associer un thread a ton agent des qu'il arrive (est cree) sur la plateforme. Tu dois pouvoir arreter ce thread avant la migration, wrapper l'agent, l'envoyer sur le site distant, l'unwrapper, lui associer un nouveau thread et relancer ton agent (en codant eventuelement la logique de reprise si besoin est).
 
Es-tu encadre pour ce travail (par des personnes travaillant dans le domaine des agentsmobiles j'entends ?)  
 
Enfin, courage...
 
A+

 
Pour la complexite : je confirme  
 
Pour le "est un thread" c'est un abus de langage pour indiquer que ses agents sont monothreades. A ce propos, bien qu'il y ait de nombreux avantages a avoir des agents monothreade, c'est un veritable casse tete a utiliser (vive les deadlocks si on ne fait pas gaffe)  
 
Pour le classloader oui il l'a indique (sous entendu) dans son premier post... ceci dit ce n'est pas un veritable probleme : charger du bytecode a partir d'un jar ou meme de bytecode recu n'est pas difficile. Il "suffit de" reecrire son propre classloader (oui je sais yaka )
 
Ceci dit je trouve tres ambitieux comme petit projet et je me demande quel est le "malade" qui lui donne a faire ca en 4h30.
 

Hm, 4h30 ils savent bien que ce sera pas possible : Il compte evidemment sur le travail supplemenaire.
 
Ce temps nous est impartie pour realiser le systeme de serveur, nous aurons ensuite encore du temps pour realiser des agents qui exploitent notre systeme.
 
Normalement nous devons travailler en binome sur ce projet mais mon binome et un peu special et je ne pourrais pas compter sur lui ou alors tres peu..... !
 

 
- Question type : Est-ce qu'il vaut mieux faire comme-ci ou comme-ca ?
- Reponse type : Ce sont deux eventualites ( mais je vous dis pas la plus facile gnark !)  
 
Actuellement j'ai les serveurs qui communiquent entre eux, ils s'envoyent les jar.....mais j'ai encore un gros probleme de classLoader ( je pensais utiliser URLClassLoader mais y'a un bleme du coté de la securité....si vous êtes courageux voir mon post "URLClassLoader et securité" ).
 

 
Euh... travail supplementaire ou non 4h30 c'est illusoire... (ou alors je n'ai pas compris ce qu'ils voulaient et je vais chercher midi a 14 heures.)