J’ai une question pour les accros du reseau et de Java. Je voudrais realiser une application distribuee mais sans serveur dedie. En clair, j’ai n clients. Ils se connectent les uns avec les autres et possedent tous un objet commun qui est distribue sur le reseau. Lorsqu’un nouveau client arrive, il effectue une requette pour recuperer l’objet en question. Lorsqu’un client sort du reseau, l’objet pert une reference mais reste actif pour tous les autres clients. Lorsque le dernier se deconnecte, l’objet est detruit. De meme, un client demarre son application, il s’enregistre et cree cet objet. Un autre arrive, il se connecte au premier et recupere l’objet … ect…
Donc, ma question: quelle techno utiliser? Corba? RMI? Je crois me souvenir qu’il faut un serveur distributeur d’objet… Echange de donnee via un protocole TCP-IP (SAOP, socket)? L’objet en question n’est pas tres gros (genre - de 100 ko). Des suggestions?
PS: cool, ca marche maintenant l’ecriture sous FireFox! Grand Bonheur ce Lundi matin
Je sais pas quelle est ton application que tu veux realiser mais j’ai des serieux doutes sur la scalabilite, la fiabilite, et l’utilite de la chose, implementee comme tu le decris. Je vois beaucoup de problemes tres handicapants avec ce genre de solutions. Par exemple tu mets enormement des stress sur un client au hazard dans ton reseau et comme modele c’est pas tres fiable. Si l’instance de l’objet est vraiment unique et centralisee sur le premier client comment reagir lorsque ce client disparait soudainement du reseau? Re-creer l’objet sur un autre noeud? Quid de l’etat? Si l’etat est pas important quel interet a guarantir l’unicite de l’instance de l’objet? Quoi que tu fasses de toute tu auras pas de veritable unicite objet, tu auras des “squelettes” leger/transparents qui redirigent tes requetes vers une instance distante. A faire des objets “creux” comme ca tu t’expose a plein de problemes super complique dans un reseau P2P ou la fiabilite des noeuds est tres tres loin d’etre guarantie.
Corba, RMI, etc sont que rarement adaptes a ces architectures et penser “objet reparti” est, je pense, pas le bon modele pour la situation. C’est pas parceque qu’on “peut le faire”, ou que ca semble “pratique a implementer une fois que ca marche” que c’est la meilleure solution. En voulant te placer au niveau objet, tu veux t’abstraire de la couche de communication et la rendre transparente, pour effacer la bordure du reseau entre chacun des noeuds de ton application. C’est pas une bonne idee. Les problemes de latence, de fiabilite des noeuds, de volume des donnes transmise, de nombre des echanges font que de toute facon tu peux PAS t’abstraire de la couche de communication au niveau applicatif. Au final tu te retrouves avec un gros tas de hacks qui marchent pas pour essaye de forcer une couche d’abstraction qui fuit de partout. Ca fuit deja de partout dans un cas comme client/serveur, alors en client/client P2P c’est 50 fois pire. Il y a un super interview de Don Box a ce sujet d’ailleurs sur la volontee d’abstraire la couche de communication completement dans tout les cas et pourquoi c’est un modele completement irrealiste et impraticable dans le monde reel. La realite c’est que tu veux un constrole fin et granulaire sur la communication et sur le mode de comm et que les contraintes du genre “unicite d’instance” sont pas du tout adaptees.
A mon avis tu penses trop a “caser une techno sur un probleme”, plutot que de bien definir ton probleme, tes solutions et voir quel est la solution qui repond le mieux a ton probleme. La fait de penser “je veux un objet distribue” c’est deja forcer une solution donnee sur ton probleme. Je pense perso qu’il vraudrait mieux que tu recule d’un pas, que tu analyse tes besoins et que tu commence a architecturer ta solution a partir de la. Si tu veux bien partager plus de details sur ce que tu cherche a resoudre je suis sur qu’on pourra t’aider a definir une solution qui me semble plus adaptee a ce que tu a presente comme environnement. Ce message a été édité par GloP le 15/03/2004 Ce message a été édité par GloP le 15/03/2004
Merci pour ta reponse GloP. Quelques points que je veux preciser:
- l’instance unique de l’objet n’est pas forcement une contrainte forte. Comme je le disais en fin de mon thread, je voulais juste savoir s’il etait possible de faire ca en instance unique ou s’il faut que je developpe en utilisant un bon vieux socket qui echange des donnees!
L’objet a partage est de petite taille, la duplication sur chaque noeud du reseau ne pose pas de probleme de memoire. Par contre, la methode ne me plaisait pas trop, tres proche du bon vieux C et pas tres objet!
- La mise en place d’une instance unique a la P2P me semble aussi bien casse gueule…
Pour information, cette application sera utilisee pour la mise en place d’un travail collaboratif sur des petites donnees. Les utilisateurs ne veulent pas dependre d’un serveur central de donnee et veulent aussi pouvoir continuer a travailler meme si l’un d’eux vient a se deconnecter du reseau.
Si tu as d’autres idees, je suis toujours preneur.
PS: tu parles d’une interview de Don Box, tu peux donner le lien stp?
Corba, avec JavaOrb par exemple peut te permettre de réaliser ce que tu souhaites.
Je n’ai pas le temps de développer, mais je peux te refiler des pointeurs sur ce genre de choses si cela t’interesse.
PS pour GloP: hébé, mais c’est trop la classe l’éditeur HTML sous mozilla pour cafzone Merci bien m’sieur !
Corba ne me parait pas approprie, mais je me gourre peut etre… Ton stub doit etre implemente dans le serveur qui controle la distribution des objets. Hors la, pas de serveur dedie…