Discussion :

[knono]

Bonjour à toutes et à tous,

Soit un serveur applicatif JAVA qui communique avec ses clients, JAVA également, en RMI sur le port 7701.
Soit le passage du serveur applicatif d'un serveur physique à un autre.
Soit l'ouverture sur le nouveau serveur physique du port 7701 (c'est mieux).
Le serveur démarre correctement. L'enregistrement du "RemoteObject" dans la registry se déroule sans erreur.

Et bien la connexion entre serveur et client ne fonctionne pas !
Alors surveillance des ports avec les ingés du Système et là ôh surprise, une tentative de communication sur le port 33084, jamais explicitement défini .
> ouverture de ce port

Et là ça continu, tentative de communication sur un autre port !

Donc je me suis dis, no problemo, ça doit être un peu comme le FTP : y a le port 21, puis tout une plage de ports pour le retour ... sauf que je n'ai rien trouvé dans ce sens dans la littérature sur Internet concernant RMI ou les sockets JAVA.
Quelqu'un aurait-il une petite idée ? Voir connaissance d'une plage de ports particulière à "libérer" pour le bon fonctionnement du RMI ?

Non car allez savoir pourquoi, les collègues du Système et du Réseau ne sont pas chaud pour m'ouvrir les ports les uns après les autres sans justification formelle ...

Note : pour vérifier, j'ai fais un petit programme JAVA qui ne fait QUE la connexion au serveur, histoire d'être sur qu'il n'y avait pas un truc planqué dans le client

Merci d'avance et bon courage à vous, pour qui août rime avec boulot plutôt que sable fin,

[tchize_]

le port 7701 est le port de ton rmiregistry. Il s'agit d'un objet disposant de méthode permettant de récupérer d'autres objets RMI. Tout objet exporté par RMI a son propre port. C'est le cas des objets que tu exporte explicitement via unicastremoteobject, mais c'est aussi le cas implicite de tout objet fourni en paramètre / valeur de retour et implémentant l'interface RemoteObject.


Quand à l'absence de litérature, dans la doc d'oracle, Hello World relatif au RMI, c'est marqué:

The static method UnicastRemoteObject.exportObject exports the supplied remote object to receive incoming remote method invocations on an anonymous TCP port and returns the stub for the remote object to pass to clients. As a result of the exportObject call, the runtime may begin to listen on a new server socket or may use a shared server socket to accept incoming remote calls for the remote object.

tu peux d'ailleurs très bien avoir ta registry sur un serveur A et ton remote object sur un serveur B avec le client sur une machine C.

[knono]

Bonjour tchize_,
Merci pour ta réponse.
Je crains effectivement d'avoir un peu tout mélangé : et la récupération de l'objet sur la registry, puis la communication à proprement parlé ensuite.

Puisque tu sembles maîtriser le sujet, puis-je me permettre de te solliciter encore un peu ?
- Quels sont les ports de communications utilisés par les RMI ?
- Y a-t-il moyen de paramétrer le client et/ou le serveur afin de définir une plage de ports de communication ?

En te remerciant par avance,

[tchize_]

1) ils sont anonyme -> Donc mis à part qu'ils sont supérieurs à 1024, rien de fixe
2) pas que je sache. Seulement, RMI c'est un protocole de haut niveau, il y a le language de communication sous-jacent. Celui par défaut de sun/oracle utilise de nombreaux port. O peux bidouiller pour un tunnel http, mais c'est très pénalisant en performance. Il exise aussi des implémentations tierces de RMI, certaines seront peut-être plus "firewall friendly".

Tu peux aussi essayer de fournir ta propre implémentation de RMISocketFactory qui limiterais les ports.

PS: jamais essayé de traverser un firewall avec RMI

[knono]

Merci pour les précisions.

Bonne continuation,