Discussion :

[joho]

Bonjour (ou bonsoir c'est selon)
Je penses que je postes sur le bon forum (prévenez moi si ce n'est pas le cas) et j'ai un gros problème.


Je suis etudiant et aurait aimé avoir une histoire serieuse avec la programmation réseau.

Je voudrais echanger des données entre deux PC en UDP par Internet. l'un(C1) étant derriere un routeur (NAT) et l'autre(C2) ayant une adresse publique .

J'ai donc immaginé une configuration ou C1 envoi un message a C2.
Ce dernier , recuperant l'adresse et le port de C1 lui renvoi un message.

Cependant, cela ne fonctionne pas,
il y a bien un aller (C1 vers C2) mais pas de retour (C2 a l'air d'envoyer correctement et je crois que le paquet s'ecrase sur le routeur).

Est ce que l'un d'entre vous ayant rencontré le meme probleme (et trouvé la solution) pourrait m'aider :
Sinon c'est déja très gentil d'avoir pris la peine de me lire alors MERCI

[Gfx]

Comment fais-tu pour verifier si les paquets passent ?

[joho]

lorsque j'envoie un message à C2 (Machine n'etant derriere aucun routeur) il affiche un message avec le nom du paquet et l'adresse IP de la personne qui l'a envoyé (grace a instance de datagramPacket.getSocketAddress et comme C1 est derriere un routeur, c'est l'adresse du routeur) ensuite, j'envoie vers C1 avec l'adresse que j'ai recupérée et normalement C1 affiche un message lorsqu'il recoit un paquet .

J'ai un petit peu étudié les NAT et normalement c'est normal qu'il le paquet envoyé par C1 aie l'adresse du routeur et un port défini par lui . Et normalement, en renvoyant un paquet vers ce port je devrais reussir a contacter C1 masi ca ne passe pas .

Tout ca pour dire que je fais des affichages lorsque je reçois des paquets. J'ai testé des logiciels comme ethereal mais je n'ai pas de droit sur la machine qui me sert de test pour C2 Donc ce logiciel ne me sert que pour la moitié des test.

[jowo]

Regarde du côte de JXTA. Chaque technologie "P2P" est confrontée au problème des NAT, firewall.

Sinon tu as les protocoles STUN et TRUN qui feront ton bonheur
voir

[joho]

Ben en fait j'aurais bien aimé m'en passer si c'était possible. Ca a l'air d'être un gros truc et moi je veux juste passer une NAT .
Ca me semble etre comme pour déplacer un sceau de sable en utilisant un 38 tonnes

[jowo]

Ben en fait j'aurais bien aimé m'en passer si c'était possible. Ca a l'air d'être un gros truc et moi je veux juste passer une NAT .
Ca me semble etre comme pour déplacer un sceau de sable en utilisant un 38 tonnes

Pour une NAT, tu as le protocole TURN. Etudie-le et peut être que tu auras une solution simple pour ton problème de NAT.

TURN: Traversal Using Relay NAT de J.Rosenberg, R. Mahy, C. Huitema

[joho]

Merci a toi homonyme avec une lettre qui change
Je vais aller regarder

[xavlours]

Bonjour,
Les NAT ne peuvent pas relayer de l'UDP de base, il faut ajouter des choses (je ne connaissais pas tant d'alternatives).

Le plus simple, léger pour le NAT et rapide à coder est à mon avis l'utilisation de TCP.

[joho]

Ben en fait c'est ce que j'essaie de fare, le protocole STUN. http://fr.wikipedia.org/wiki/STUN
j'envoie des informations a un serveur alors que je suis derriere un routeur NAT et ce serveur me reponds ... sauf que la, il ne me reponds pas ... ou plutot la reponse n'arrive pas .
J'envoie un message vide a un serveur alors que je suis derriere un routeur et met la socket qui a permis l'envoi en mode ecoute (avec instance de DatagramSocket.receive(instance de datagramPacket) puis le serveur me renvoie un message. (plusieurs fois au cas ou je ne me serais pas mis en mode ecoute assez rapidement )
Mais la reponse a l'air de s'ecraser lamentablement sur le routeur

Le plus simple, léger pour le NAT et rapide à coder est à mon avis l'utilisation de TCP.

Et pour TCP, mon but etait au départ de passer 2 NAT avec un serveur relai (oui... ca ressemble a du P2P ) et g entendu dire qu'avec la methode que j'utilise (ou plutot que je voudrais utiliser) UDP passe 80% des routeurs et tcp 60%.

[xavlours]

A priori, je dirais que TCP a beaucoup plus de chances de passer les NAT qu'UDP (notamment les NAT dynamiques auxquels tu dois etre confronté).
Je ne sais pas d'ou tu tiens cette information, mais je n'y crois pas trop, quelle que soit la méthode que tu utilises.

Si tu préfères tout de meme UDP et STUN, regarde ce document, il pourra t'apporter des infos sur ce qu'il faut faire pour faire passer les messages UDP à travers diverses configurations de NAT.

[joho]

Merci pour le document ... il va me servir beaucoup ... je vais aller regarder

[mitje]

xavlours :

Les NAT ne peuvent pas relayer de l'UDP de base

Tient donc, et pourquoi alors ?

et aussi :

Le plus simple, léger pour le NAT et rapide à coder est à mon avis l'utilisation de TCP.

tu trouves que tcp c'est plus simple qu'udp toi.

et encore :

A priori, je dirais que TCP a beaucoup plus de chances de passer les NAT qu'UDP

Vraiment à priori alors, praceque le routage n'a jamais était un jeu de hasard.

Pour en revenir à ton problème :
essaye de faire un traceroute dans le sens ou tu le fait dans ton exemple.
Histoire de voir si le routeur NAT a un comportement particuliers vis à vis du protocole UDP ce qui m'etonerai grandement parceque tout un tas d'applications utilise ce protocole.
Ensuite, demande à l'administrateur du routeur incriminé si effectivement il voit des packets qui sont refusés ou dropés ayant pour source ta machine avec une IP publique. Et si c'est le cas pourquoi sont il refusés (dropés) et à quel moment ?
Etant donné les informations fournies, il n'est pas evident que ce soit le routeur dont tu causes qui soit le fautif.
Donc donnes nous plus d'infos.

[joho]

Merci a tout le monde ... JE PASSES UNE NAT le probleme etait un probleme de code, (j'apprends au fur et a mesure) . La méthode était bonne (c un petit peu une implementation de STUN en fait)
UDP passe donc tres tres bien avec un NAT les messages s'entendent clair et dort et c'est trop bien voila .
Merci a tout le monde.

et pour le fait que 80% des routeurs gerent le passage des NAT avec UDP ma source m'a donnée sa source :http://www.brynosaurus.com/pub/net/p2pnat/

[xavlours]

Puisque ton problème semble résolu, je me permets de polluer le sujet avec mes justifications pour mitje :

Les NAT ne peuvent pas relayer de l'UDP de base

Tient donc, et pourquoi alors ?

J'avoue j'avais un peu oublié les NAT. Je pensais uniquement aux NAT dynamiques à traduction de numéro de port, alors qu'il en existe beaucoup d'autres. Je me suis rendu compte de mon erreur en lisant les liens que j'ai donné ensuite .

Le plus simple, léger pour le NAT et rapide à coder est à mon avis l'utilisation de TCP.

tu trouves que tcp c'est plus simple qu'udp toi.

Bien sur que non ! Il ne manquerait plus que ca ! Mais TCP est plus simple à mettre en place en Java que STUN et consorts. C'est bete à dire, mais il faut parfois justifier l'utilisation d'UDP plutot que TCP.

A priori, je dirais que TCP a beaucoup plus de chances de passer les NAT qu'UDP

Vraiment à priori alors, praceque le routage n'a jamais était un jeu de hasard.

Je ne suis pas sur, est-ce ironique ? En tout cas ca m'inspire deux réactions.
- Je crois que TCP passera tout NAT qui se respecte, mais au cas ou j'emettais quelques réserves, surtout après son affirmation statistique.
[EDIT] j'ai lu ta documentation sur http://www.brynosaurus.com/pub/net/p2pnat/ et en effet, je comprends tes statistiques. Vivement IPv6.[/EDIT]
- Le routage est souvent aléatoire, notamment sur ... les NAT répartiteurs de charge ! C'est d'ailleurs ce principe qui est à l'origine de la plupart des déséquencements de messages.

Si je persiste dans l'erreur, je serais heureux de continuer la discussion.

[mitje]

Dans un premier temps je pense que le NAT est a dissocier du routage.
Pour illustrer cela prenons un exemple :
Sur Linux il existe deux type de NAT :
1 - Le Source NAT (SNAT): consiste à changer l'adresse IP source d'un packet et ce après que celui-ci est était routé.
2 - Le Destination NAT (DNAT): consiste à changer l'adresse IP de destination d'un packet avant que celui-ci ne soit routé.

- Le routage est souvent aléatoire, notamment sur ... les NAT répartiteurs de charge ! C'est d'ailleurs ce principe qui est à l'origine de la plupart des déséquencements de messages.

Si je persiste dans l'erreur, je serais heureux de continuer la discussion.

Non je suis désolé, je pense que le routage n'est pas aléatoire. Dans la mesure ou le routage consiste à choisir un chemin, on ne choisi jamais un chemin au hasard, mais le chemin "qui est le plus approprié" pour envoyer le packet vers sa destination CQFD.

Pour les répartiteurs de charge :

Je pense que le séquencement des packets est conservé dans la mesure ou tu utilises un protocole approprié comme TCP par exemple, pour lequel tout les packets utilisent la même route (mode connecté). UDP par contre ne peut garantir l'arrivé dans l'ordre des packets dans la mesure ou deux packets différents ayant même source et même destination peuvent utilisés deux routes distinctes et donc l'ordre n'est plus garanti.
Donc dire que les répartiteurs de charges sont à l'origine du désequencement des packets IP sans parler du protocole utilisé est faux sinon incomplet.

Deplus, les statistiques que vous énoncez ne concerne pas tout le protocole TCP ou UDP mais des manières bien précises d'utilisé ce protocole (peer2peer, hole punching).
D'ailleurs je vais jeter un coup d'oeil du coté de mon NetFilter pour voir si il pose problème au niveau hole punching [/quote]

[joho]

Deplus, les statistiques que vous énoncez ne concerne pas tout le protocole TCP ou UDP mais des manières bien précises d'utilisé ce protocole (peer2peer, hole punching).

ca ne sert pas a grand chose dans le débat mais je penses que ce sont ces manières d'utiliser ce protocole que je vais aller voir (hole punching, peer to peer etc...) . Le but étant d'apprendre et puis parce que le peer to peer c'est marrant et ca a l'air de plus en plus utile (skype, azureus etc...)