Version imprimable
Bonjour
J'ai actuellement une application client serveur qui fonctionne sur Socket.
Mais a ce stade de developpement je constate que Socket est un peu lourd vu la taille des choses qui transitent entre le client et le serveur.
Pour limiter la taille des envois ou le nombre des envoi, ne vaut-il pas mieux que j'utilise RMI?
j'ai commencé a me renseigner la dessus mais est ce que c'est plsu pratique, plus performant que Socket...
A votre avis?
Merci d'avance :)
Regarde d'aborde ce qui pourrait transiter par le réseau ... il faut que cela soit sérializable si tu veux utiliser du RMI
Et puis si tu es bien avancé dans ton projet, ca risque d'etre compliqué de passer au RMI ...
Enfin moi je n'ai fait qu'un projet en RMI et par rapport au socket il y a pas mal de choses qui changent ...
Attend les réponses de "vrais" spécialistes ;)
RMI est encore plus lourd que ce que tu appelles socket...
Les sockets java utilisent le protocol TCP pour communiquer..
RMI utilise les sockets java pour echanger des messages entre stub/skeleton. Chaque fois que tu fais un appel RMI, cet appel et marshaller (encoder) ecrit sur la socket et unmarshaller de l'autre cote et transmit a l'application ...
RMI risque aussi d'introduire des limites dans la taille des donnees que tu desires envoyer ...
Bulbo :wink:
et bien je sais pa si tu te rapel un peu ce que je faisai c dernier tem avec mes socket ^^
l'histoire avec le transfert de fichier et la taille et tou et tou
je transmettai un fichier de donnéees seialisé a une interface client, qui permettai de faire des recherches dans ces donnée
une foi que on a trouvé ce que l'on cherchait , on selectoinn des element et on les renvoi au serveur... ca c'est le fonctionnement actuel
maintenan ce qui doit etre changé c'est que c'est le client qui envoi ses parametre de recherch au serveur, le serveur lui, renvoi seulemen les resultat de recherche, le client poura aussi envoyer les elements choisi au serveur pour d traitement ulterieur...
On m'a suggéré RMI...mais j'ai peur que ca ne soit pa adpaté et que je recommence qqc dan le vide comme pour mes sockets....
Typiquement RMI peut etre utilise (ou CORBA, ou SOAP, ou XML-RPC) dans ce cas la ...
Les differences:
Tu n'as pas besoin de te preoccuper du protocol de communication entre client/serveur.
en RMI cela se resumera a des appels de methodes sur le serveur
RMI sera de toute facon plus lourd qu'un petit protocol proprietaire bien ficele ..
La taille des donnees pouvant etre transmises par RMI a peut-etre (surement) une limite, limite qui n'existait pas avec un protocol proprio ...
Bulbo :wink:
Quand tu di limite...il refusera d'envoyer qqc d etrop gro et il va me bipper a la figure?
ou alor il le segmentera tt seul
ou alor est ce ke si je marrange pour segmenter mes envoi (si c possible) ca peut s'arranger?
Le probleme etait qu'avec mon apli actuelle, cque ca ne fai pa tre propre. il fallait juste un interface du coté client, moi javai une interface qui recuperai un gro fichier de données (enfin bon c pa vraiment ma faute :) je men sui accomodé )
Desole, je manque de precision la dessus, je ne suis pas un expert RMI, j'ai entendu dire que RMI avait du mal avec de gros objets ..
Si ton probleme est un probleme de performances, RMI ne va surement pas le resoudre ...
Si tu trouves que ton code n'est pas tres propre je ne pense pas que cela soit la faute des sockets .. et tu risques de faire encore pire avec RMI :lol:
Moi lorsque je dois faire une appli dans le genre de la tienne, je definis des classes qui s'occupent du protocol et cachent les specificites de la communication...
En gros l'interface de ces classes me proposent seulement les methodes dont j'ai besoin et derriere j'utilise une socket pour faire le boulot..
RMI fait a peu pres la meme chose, mais il faut generer des stubs, des skeletons, lancer la registry, et j'en passe et des meilleurs ...
Pour regler tes problemes de performances, je serais toi j'analyserais mes flux pour voir si des fois je pourrais pas envoyer moins de choses ou faire des traitements avant la communication afin de ne pas surcharger mes sockets ...
Bulbo :wink:
Et bien mahleuresement j'effectue tous les traitement necessaires avant l'envoi...
sinon par exmple le fichier ke jenverrai ferai 40Go....mai il fera 13 meg vu ke j'ai traité les info....
mais sinon je serai plutot de l'avi de garder mon fonctionnement par socket
mai mon probleme c'est les flux, j'ai limpression que une foi que j'ai di qu'un flux etait d'un certin type, je ne peu plu rien en faire d'autre...
et puis le souci etait maintenan que le vclient soit juste une simple interface qui me sert qu'a laffichage des resultat de recherche... et qu'il n'ai pa besoin de telecharger un fichier etc, une interface tt bete..
Pour la taille des donnees tu peux essayer de zipper le resultat, cela sera toujours ca de gagne ..
Je ne vois pas tres bien ce que tu entends par type de flux ...
Pour ce qui est du client, je pense qu'il te suffit de modifier ton protocol pour matcher les nouvelles specification et le tour est joue ..
Bulbo :wink:
j'enten par type de flux
kan je fai new DataOutputStream(S.getOutputStream())
et bien si je veu apre que ca soi FileOutputStream je c pas commen faire
et euh est ce que tu pourai developper ton idée de "matcher les specif"? je vois pa bien a quoi tu pense
Pour les types de flux:
Le mieux c'est de toujours utiliser un simple OutputStream et de faire la conversion de l'autre cote..
Lorsque tu utilises un DataOutputStream, les donnees sont serialisees avant d'etre ecrites sur la socket et deserialisees de l'autre cote ...
Si tu fais ca pour ecrire un gros fichier, cela peut effectivement etre long, tu dois d'abord creer un tableau (ou une string) contenant toutes les donnees pour ensuite les ecrire sur la socket..
Avec un OutputStream tu peux ecrire les donnees au fur et a mesure de la lecture ..
Pour ce qui est de "matcher les specifs":
Le client devant envoyer d'autres types de requetes au serveur, il suffit de faire la liste de ces requetes et de mettre au point un petit protocol qui supporte tout ca ..
Bulbo :wink:
*la galere*
javou etre demotivé pour ojourdui qqc la solution pour lakel j'opte j'a 1 journée chiante a changer mon code....
Enfin bon, merci en tou cas de m'avoir eclairé, mai je croi ke je vai devoir utiliser RMI (contraint par l'employeur ^^ :) sigh)