Discussion :

[Deckname]

Salut,

J'ai un émetteur et récepteur qui communiques via un protocole RTP fournis pas JMF, cela fonctionne parfaitement mais le truc c'est que je suis obligé d'utiliser le nat. Cependant j'ai vu qu'il était possible de le contourner via le hole punching.

Mais j'ai du mal a comprendre comme sa fonctionne et comment je pourrait l'utiliser avec java ? Il y a trés peut d'info en français dessus

De ce que j'aurais compris, si admettons que je veux créer une session rtp avec un serveur. Le serveur vas prendre le rôle de l’émetteur et le client du récepteur.

Le principe c'est que le client doit d’abord envoyer un packet au serveur pour "percer" le nat et ensuite la session peut commencer ?

(Je me suis peut être trompé, le hole punching et bien une bonne solution ?)

Merci.

[thelvin]

Hello,

le hole punching ne marche pas en situation client/serveur, c'est une technique utilisée (dans les rares cas où elle marche) pour les connexions pair-à-pair arbitrées par un serveur tiers (qui lui n'a aucun problème de NAT).

En client/serveur, le client n'a aucun problème de NAT. Et si le serveur a un problème de NAT, le hole punching ne peut pas l'aider, car c'est celui qui est derrière un NAT qui doit percer un trou pour laisser passer celui qui essaie de lui parler. Or le serveur ne connaît pas les clients pour lesquels il doit percer des trous.

La solution est de ne pas avoir de problème de NAT, typiquement en le configurant pour laisser l'accès libre au port du serveur.

[Deckname]

Salut,

Non le serveur est bien configuré a ce niveau-là. Ça fonctionne que si les ports de ma box sont ouverts.

Donc comment je peut faire pour contourner la nat du client ?


Merci.

[hwoarang]

L'utilisation typique du hole punching, c'est le jeu video ou bien de la prise en main d'ordinateur à distance (type VNC).
Dans une architecture réseau, ca parait evident, le serveur doit etre joignable par le client (d'un point de vue réseau). Le probleme, c'est que le serveur est parfois dans une configuration réseau qui ne permet pas au client de se connecter. Typiquement, derriere un routeur/firewall, un nat, ...
Et l'utilisateur ne sait pas toujours configurer son réseau pour ouvrir le bon port sur la bonne machine (par exemple pour heberger une partie d'un jeu video).
La configuration des réseau est beaucoup plus permissive en sortie qu'en entrée (en gros, tu peux surfer sur n'importe quel site mais un ordinateur sur internet ne peut pas se connecter à ton PC). C'est la qu'intervient le hole punching. L'idée, c'est de mettre un serveur accessible par n'importe quelle machine depuis internet. Les deux machines que tu veux connecter se connectent sur le serveur qui permet le hole punching. D'un point de vue réseau, elles se connectent toutes les 2 en sortant, ce qui permet de s'affranchir d'une configuration qui peut etre laborieuse et pas evidente pour l'utilisateur lambda.
Ensuite, le serveur joue le role de passerelle en envoyant les paquets entre tes 2 machines.

Maintenant, pour savoir si c'est utilisable dans ton cas, ca depend de ton application coté serveur. C'est une utilisation tres différente de celle de serveur classique donc ca ne fonctionne probablement pas en changeant une ligne dans un fichier de config.
A mon avis, le plus simple est de configurer ton réseau pour rendre ton serveur accessible. L'interet du hole punching est plutot de permettre à des utilisateurs non initiés de servir de serveur, sans avoir à faire la config qui serait necessaire autrement.

Par contre, dans ton message, tu parles d'envoyer un paquet du client au serveur pour percer le nat. Qu'est ce que tu entends par la ? Peux tu expliciter ta config réseau ?

[Deckname]

Merci pour cette explication

Quand je parle de percer le nat je parler du hole punching et de sont principe de fonctionnement. Mais justement il faut voir le serveur comme le second client, je veux juste au final crée une session RTP de streaming du serveur (qui prend le role d'un client) a un autre client sans avoir ces soucis de nat si je veut je peut même remplacer le serveur par un second client pour les tests. Mais justement la ou je ne comprend pas le hole punching, c'est que si les deux machines sont configurées en sortie comment peuvent elles recevoir ?

[hwoarang]

Il faudrait etre un peu plus clair quand tu parles de serveur. Tu parles de ton serveur applicatif ? Ou bien du serveur permettant le hole punching ?

Clairement, pour utiliser le hole punching, il faut ajouter un serveur. Ce role ne peut pas etre joué par le client ou le serveur applicatif.

je veux juste au final crée une session RTP de streaming du serveur (qui prend le role d'un client) a un autre client sans avoir ces soucis de nat

Donc tu veux que ce soit le serveur qui prenne l'initiative de se connecter directement au client ? Dans ce cas, il faut que le client soit joignable (pas gagné) et que le serveur sache ou il est sensé se connecter. Comment tu comptes faire pour ce point ? Techniquement, il y a des solutions mais je pense qu'ici, tu pars sur une mauvaise solution dans la mesure ou tes clients ne seront probablement pas beaucoup plus joignables que ton serveur.

Mais justement la ou je ne comprend pas le hole punching, c'est que si les deux machines sont configurées en sortie comment peuvent elles recevoir ?

La, on parle juste d'ouvrir une socket. Il y a une difference de configuration réseau pour se connecter en entrant ou en sortant. Mais une fois la socket ouverte, des données peuvent etre envoyées dans les 2 sens.

[Deckname]

Salut,

Je parle bien d'un serveur applicatif et je veut que se soit le client qui connecte au serveur mais le soucis c'est que pour crée un session rtp avec jmf c'est le serveur qui doit prendre l'initiative et je ne trouve pas de solution pour ouvrir une socket a partir du client et ensuite faire la session.