J’ai créer une application java RMI (client/serveur) qui fonctionne très bien dans un réseau local. Je ne rencontre aucun problème.
J’ai placé mon serveur RMI en dehors de mon réseau local (sur un machine distante) et je souhaite faire fonctionner mon application. Mon problème est le suivant :
Lorsque mon serveur est distant, les callbacks sur mes clients ne fonctionnent plus, ce qui parait logique puisque le client en question est placé derrière un routeur et que ce même routeur fait du NAT. Lorsque mon serveur essai donc de faire le callback il essai d’utiliser mon adresse interne (192.168.1.x) et évidemment il ne la trouve pas.
Comment puis-je faire pour que mes callbacks fonctionnent??? Il faudrait entre autre arriver à envoyer au serveur l’adresse global du client non (avec l’adresse publique du routeur)???
Merci d’avance.
si il faut plus de détails n’hésitez pas à demander!
Ton raisonnement ne me parait pas correct sur le point de vue du fonctionnement de ton routeur.
Si ton routeur fait effectivement du nat, alors ton serveur distant voit l’adresse qui se trouve du coté du serveur distant de ton routeur et dcnc a ce moment la, ton serveur distant essaye simplement de répondre a ton client. Si cela ne passe pas c’est que les paquets en retour sont rejettés.
Si ton routeur ne fait pas de nat alors ton serveur distant doit savoir quelle gateway utiliser pour joindre ton serveur. ce serait une histoire de route.
Merci de bien vouloir nous éclaircir sur l’adresse ip source des connections vers ton serveur RMI
Bonjour, tout d’abord merci pour ta réponse.
L’adresse ip source de ma machine cliente est 192.168.1.33.
J’ai fait un test afin de vérifier l’adresse du client recu par le serveur. Je demande au serveur de se créer un fichier texte d’afficher dans ce fichierl’adresse ip du client qui se connecte. Voici ce qui est inscrit dans ce fichier (situé sur le serveur)
Ceci montre bien que l’adresse recu par le serveur (192.168.1.33) n’est pas une adresse routable non??? Et donc que les callbacks ne peuvent etre effectué???
Comment puis-je donc faire pour que l’objet Remote client que j’envoi au serveur contienne une adresse routable?
Ce lien (en anglais) donne des informations sur ce problème mais je ne comprend pas très bien en quoi consiste la solution.
Peut être que ca vous parlera plus. (Rubrique "beware of NAT)
En fait bon c’est le deuxième cas que j’ai énoncé, ton routeur ne fait pas de nat, car ton serveur voit l’adresse ip inofficielle de la machine émettant la connection.
donc deux solutions :
soit tu actives le NAT
soit tu ajoutes une route a ton serveur pour qu’il sache faire le chemin de retour
Haaaaaaaaaa je pense voir ou tu veux en venir, mais je pense qu’il y a eu une mésentente :D:D:D
Je t’assure que mon routeur fait bien du NAT et qu’il est bien activé…
mais en fait ce que j’ai peut etre oublié de signaler (je l’ai pas fait car j’ai imlémenté mes callbacks comme dans la plupart des tutoriaux) c’est que pour se connecter au serveur, les clients utilisent un méthode partagées par le serveur et lui passe en meme temps une référence remote sur lui même afin que le serveur puisse par la suite faire les callbacks :
Du coté client je faits donc ceci avec refServer qui est la référence sur le serveur obtenu avec le RMI registry.
refServer.connect (Remote refclient)
Donc si on veut le serveur ne détecte pas d’ou vient l’appel à la méthode mais recoit la référence en paramètre. Cette référence est donc déterminée par le client avant de sortir sur Internet. C’est pourquoi elle est 192.168.1.x et non pas globale meme avec le NAT.
Donc effectivement comme tu dis, il serait idéal de pouvoir détecter l’adresse global (du coté serveur) et de l’ajoutée au remote pour que le serveur puisse faire le chemin inverse, et c’est justement là que je suis coincé. En fait je sais meme pas si c’est possible de faire ce que je dis
Voilà j’espère que j’ai été un peu plus clair qu’au début.
Edité le 19/12/2007 à 00:28
Les autres articles sont importants aussi, tu veux faire du “push” au lieu de “pull”, et le Workaround est p-e une piste: www.augursystems.com…
Si tu instancie bien tes sockets depuis le client pour accéder au server ça passeras bien par le NAT: le serveur est connu sur le NAT. (reste à bien reprendre la bonne socket en fonction du client)
le callback rmi doit faire l’inverse connecter un socket depuis le serveur en donnant l’adresse du client: or même en donnant l’ip du NAT du client, le NAT ne sait pas quel client adresser donc ça ne peut pas marcher.
Avec un sniffer, tu pourrais voir comment le RMI connecte ses sockets.
Merci pour ta réponse deltree, j’avais lu un peu les autres articles mais un peu en diagonale, ils sont effectivement tous intéressant :)
Tu as à mon avis mis le doigt sur une solution éventuelle avec le Work-around! Je vais chercher dans cette direction.
En faisant des recherches j’ai égalemement trouvé des informations sur la façon dont RMI peut traverser des firewalls et des proxys. Car le NAT n’est pas seule difficutlée lorsque l’on travail avec RMI ailleures que dans un réseau local.
Les solutions dont j’ai entendu parlées étaient le tunneling http et RMIproxy…Ca peut tjs servir
Edité le 19/12/2007 à 23:03
