oui, coder en tenant compte des spécificité du RMI. Si tu considère que ton client pourrait ne pas être visible, et donc ne pas pouvoir accepter de connection entrantes, il ne faut pas exporter d'objets RMI coté client!
Version imprimable
oui, coder en tenant compte des spécificité du RMI. Si tu considère que ton client pourrait ne pas être visible, et donc ne pas pouvoir accepter de connection entrantes, il ne faut pas exporter d'objets RMI coté client!
Bonjour à tous,
Je suis bien content de voir que je ne suis pas le seul à avoir ce genre de problème.:D
Moi aussi en LAN ca fonctionne, mais pas avec un NAT (Connection Timeout)...:aie:
J'ai observer différents phénomènes que je n'explique pas encore...8O
par exemple, sur ce site , l'auteur fait état de deux ports qui seraient ouverts :
- un pour le rmiregistry qui ne serait utilisé que pour la première connexion entre le client et le serveur (par défault 1099)
- l'autre sert à toutes les autres interactions entre serveur et clients (échange d'objet...)
Mais la solution exposée sur le site ne semble pas (plus??) résoudre notre problème de Connection....:evilred:
Je pense qu'il y a deux types de thread : un qui écoute un port (ici 1099) et qui établi des sockets (dans un thread) entre le serveur et chaque client.
A l'époque où je mettais lancé dans une version qu'avec des sockets, c'est comme ça que j'avais implémenté les choses :yaisse2: (d'après les conseils lus sur internet)...
Cette vision colle aussi avec les logs de mon server qui trace bien l'arrivée du client et la méthode appelée (mais le client ne semble jamais recevoir l'objet attendu en retour de cette méthode).:yaisse2: (donc plus rien après)
Du coup, il faudrait configurer le firewall (et Cie) pour que les deux ports soient accessibles. Ou trouver le moyen de définir ce port "aléatoire".:(
Qu'en pensez vous ?
Comme vous avez essayé plusieurs pistes j'ai du mal à voir dans les messages précédents quelles pistes sont à garder...:?