Salut,
 
J'ai une applet qui communique avec un serveur. Dans ce sens tout va bien. Dans l'autre par contre probleme : certains utilisateurs sont sur un corporate LAN avec NAT (oui oui routeur ISDN ou ADSL et une adresse IP locale 192.168.x.x ou autres) et le serveur ne peut donc pas ouvrir de socket de call back...
 
Comment contourner simplement ce probleme ? (Je ne peux pas demander a tout le monde de reconfigurer le SUA de son routeur) J'ai pense a profiter des canaux de communication de JXTA mais j'aimerais la solution la plus simple a mettre en oeuvre.
 
C'est urgent merci de votre aide !

tu fais du TCP/IP direct?
 
Comment fais tu pour communiquer dans l'autre sens?

DarkLord a écrit a écrit : tu fais du TCP/IP direct?   Comment fais tu pour communiquer dans l'autre sens?

 
Si la machine n'est pas derriere un NAT c'est bete socket dans un sens puis dans l'autre... Je ne vois pas le probleme. C'est lorsque j'ai un NAT que ca merde : le serveur voit l'IP du routeur a la place de voir la machine elle meme.  
 
JXTA cree un tunnel, j'aimerais savoir quelle est la solution la plus simple pour faire du tunnelling. (Il faut que ce soit fait le plus vite possible, JXTA sera implemente par la suite, mais pas trop le temps en ce moment)

bin si ton applet ouvre une socket vers ton serveur, que tu acceptes cette connexion et que tu récpupères le in et le out, le routeur est censé faire le conversion. Ca n'a rien à voir avec ton serveur !!
 
maintenant si tu rouvres une socket toi meme par la suite ca va pas marcher ...

Euh... tu veux faire du tunelling avec un client et un serveur séparés par un proxy ou un firewall ? Enfin, en gros, le client n'a pas d'IP publique ? Bin sérieux, j'te souhaite bon courage passke j'vois vraiment pas comment c'est possible

Taiche a écrit a écrit : Euh... tu veux faire du tunelling avec un client et un serveur séparés par un proxy ou un firewall ? Enfin, en gros, le client n'a pas d'IP publique ? Bin sérieux, j'te souhaite bon courage passke j'vois vraiment pas comment c'est possible

 
JXTA... mais je cherche une solution simple...

DarkLord a écrit a écrit : bin si ton applet ouvre une socket vers ton serveur, que tu acceptes cette connexion et que tu récpupères le in et le out, le routeur est censé faire le conversion. Ca n'a rien à voir avec ton serveur !!   maintenant si tu rouvres une socket toi meme par la suite ca va pas marcher ...

 
Bon bravo tu as ENFIN compris mon probleme... (je te charie)
 
Maintenant as-tu une solution (a part JXTA) ?

tu rouvres une socket? Laisse tomber c'est impossible.

 
Bon et bien je vais devoir bidouiller...
 
Thanx anyway

 
tiens nous au courant

Mais...de toutes façons, si ton machin est une applet, je sais pas si ele a le droit d'ouvrir un port, pour choper la socket que tu veux ouvrir depuis tonserveur??

 
a vrai dire ca me parait aussi vachement zarb ce truc ...

 
Oui tu as le droit de le faire sans signer ton applet si le serveur en question est le serveur d'ou vient l'applet.
 
En l'occurance pour l'instant c'est le cas.
 
A+

euh ouvrir une connexion vers le distant d'accord. Ouvrir un socket server chez le client, pas d'accord

Chuis plutôt d'accord avec Dark, moi.....Mais pkoi tu as besoin d'ouvrir une DEUXIEME socket?? Pasque bon, pour envoyer des messages du serveur vers le client, la première socket suffit..

 
Ca marche pourtant (sisi).
 
Pour la raison de ce besoin : dans certains cas j'ai potentiellement besoin d'un 2e canal de communication pour faire p.ex. du monitoring de l'applet.
 

Bah...et ce serait pas plus simple d'ouvrir directement 2 sockets depuis l'applet, vers 2 ports différents du serveur, et la deuxième te sers de canal de comm??

 
par exemple

 
Bah le probleme est que schematiquement (en gros en laissant tomber certains trucs comme le monitoring dont je parlais plus haut)
 
L'applet se connecte a un backbone et fait une requete. Le backbone est en fait un reseau adhoc, l'applet a juste un point d'entree. Sa requete est propagee sur le backbone et si un serveur a une reponse il la donne au point d'entree...
 
Le temps qui peut s'ecouler peut etre LONG.
 
L'utilisateur peut ne pas vouloir rester sur ladite page (connexion coupee).
 
Le backbone va recontacter regulierement pour essayer de donner une reponse.
 
Des que l'applet est rechargee, peut etre qu'une reponse va arriver.
 
Autant dire "lol"
 
bon je m'amuse hein
 
A+

bin ce que tu veux faire est impossible avec une applet ...

 
Ca marche, le seul probleme est lorsque la machine cliente est sur Corporate LAN avec NAT... Et la encore tu peux bidouiller (obliger le client a rouvrir un socket... tout depend du protocole de comunication que tu adoptes : tu peux tout rendre transparent... maintenant je ne veux pas creer une usine a gaz)

une pour le pied gauche, une pour le pied droit