Je suis en train d’écrire une application P2P. Pour simplifier, on dira que c’est une application de chat genre MSN qui peut transférer de gros paquets de données. Le principe est donc : la machine A veut parler à la machine B. A se connecte à B, et alors ils s’échangent des données. Si les deux machines ne sont pas derrière des routeurs, tout va bien. A et B sont tous les deux à la fois client et serveur. Si l’un se connecte à l’autre, c’est joie.
Maintenant, si nous avons la machine B qui est derrière un routeur, c’est beaucoup plus compliqué pour A de l’appeler. Solution trouvée : utiliser un serveur central intermédiaire qui fera que ce sera B qui initiera la connexion. Scénario :
Au lancement A et B se mettent en relation avec le serveur intermédiaire S.
Machine A veut appeler machine B. Machine A en informe donc S.
S contacte B pour lui dire que A veut lui parler.
B se connecte donc alors directement à B.
La connexion est faite, les données peuvent s’échanger.
Maintenant, je bloque un peu dans le cas où les deux “peers” sont chacun derrière un routeur. Je ne vois pas comment les connecter l’un à l’autre. Je pense qu’il me manque quelques connaissances en matière de protocope TCP. Ou alors cela signifie qu’il faut obligatoirement passer par un serveur intermédiaire pour le transfert des données. Et ça, c’est pas viable.
[quote=« Drealmer, post:2, topic: 29652 »]D’après ce que j’en sais, y’a pas moyen d’initier une connexion directe dans ce cas là
edit: j’écris une seule phrase, et j’arrive encore à faire une faute, mais quel boulet[/quote]
Dans la logique de ce que j’y connais, je plussoies.
Néanmoins, il me semble que tout un tas d’applis y arrive : Skype, MSN (VOIP, vidéoconf.), Emule, etc.
Je dis bien : il me semble. Je vais me faire quelques tests.
EDIT :
1er test concluant.
J’ai installé Skype à la maison. Mon installation : 2 PC branchés sur un routeur, lui même branché sur une Freebox. Aucune configuration NAT de le Freebox.
Pareil au boulot (j’ai fait ça par VNC). Tout un réseau avec plein de machines dont la mienne. Un routeur, un modem. Pas de NAT configuré.
J’arrive à les faire se connecter dans un sens ou dans l’autre. En revanche, je n’ai pas pu vérifier le bon fonctionnement de la VOIP.
Je vais installer un packet sniffer pour voir un peu ce qui se passe, notamment s’il y a utilisation d’un serveur intermédiaire pour le transfert des données. Ca m’étonnerait beaucoup, mais bon…
[quote=“AntoineViau, post:3, topic: 29652”]1er test concluant.
J’ai installé Skype à la maison. Mon installation : 2 PC branchés sur un routeur, lui même branché sur une Freebox. Aucune configuration NAT de le Freebox.
Pareil au boulot (j’ai fait ça par VNC). Tout un réseau avec plein de machines dont la mienne. Un routeur, un modem. Pas de NAT configuré.
J’arrive à les faire se connecter dans un sens ou dans l’autre. En revanche, je n’ai pas pu vérifier le bon fonctionnement de la VOIP.
Je vais installer un packet sniffer pour voir un peu ce qui se passe, notamment s’il y a utilisation d’un serveur intermédiaire pour le transfert des données. Ca m’étonnerait beaucoup, mais bon…
Antoine[/quote]
Je n’y connaîs pas grand chose mais il me semble que pour faire ça il faut faire du “tunneling” TCP. En tous cas c’est ce que font ces applis. M’en demande pas plus.
Tu dois probablement parler du STUN qui est décrit dans la RFC 3489 : Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)
Skype utise un dérivé de ce protocole.
En gros, pour confirmer ce que dit Dreamler, et infirmer mon « ça m’étonnerait beaucoup… » :
si la connexion directe est possible, joie.
si un des peers, ou les deux, sont derrière un NAT/FW : on passe par un proxy, donc par un serveur intermédiaire
En fait skype utilise son fameux mode « super node » si aucune des machines ne peut accepter de connexion depuis l’extérieur.
Je précise au passage que NAT != routeur (toute machine sur le net est forcément derrière des routeurs) : si tu veux parler de NAT, alors parle de NAT. Ensuite, ce n’est pas forcément parce que tu es derrière un FW/NAT que tu ne peux pas recevoir de connexions : il suffit de mapper le port.
Sinon, je pense que MSN fait passer les transferts de fichiers via ses propres serveurs.
Non MSN ne fait pas passer les transferts par ses serveurs par contre skype oui.
Le test tout simple peut se faire en réseau local avec les deux machines reliées au net. Avec MSN le débit sera de l’ordre de celui du réseau local, avec Skype ce sera très lent…
A ce propos Skype est déconseillé pour ce qui est des conversations professionnelles car il est très sujet aux « écoutes » mais pour parler à tata jeanine il n’y a bien sûr aucun risque
Sinon y a des moyens avec un serveur tiers pour aider a etablir la connec entre deux peer derriere un NAT en « grugeant » la maniere dont fonctionne les NAT/firewall de base qu’ont la plupart des gens. En generant ses propres paquets on peut leur faire croire qu’ils arrivent a etablir une connection directe de l’un a l’autre et une fois qu’ils croient tous les deux que les paquets sont toujours « sortants » ou des reponses a un « sortant » le serveur tiers peut lacher l’affaire et les laisser ses debrouillers. Je connais pas les details, je sais juste que ca marche (meme si pas forcement dans tous les cas, ca aide bcp pour pas faire passer les donnees par un serveur central) et je pense pas que ca soit specialement documente ou standard
C’est pas mal comme concept. Mais il y’a une condition pour que cela fonctionne : il faut que la machine tiers puisse spoofer les IP des paquets, et de plus en plus de fournisseurs empêchent les paquets spoofés de quitter leurs réseaux. Donc il faut être en mesure de garantir que ces paquets spoofés puissent sortir…
Connaissant une application avec des millions d’utilisateurs qui utilise une technique similaire tous les jours en production depuis maintenant un bail, ca marche plutot pas mal du tout :P. Maintenant meme MSN/Live Messenger, qui pourrait potentiellement bien beneficier de la chose, je suis a peu pres sur qu’ils utilisent pas. Cela dit je vois d’ici les headlines slashot si ils le faisaient… donc ca reste quand meme limité/confidentiel comme application.
A la fin, je présente les différents scénarios de “connexion” (plus du transfert de données). Le tout en UDP. Comme tu peux le voir, y’as tout un tas de scénarios possibles (même si STUN aide pas mal). C’est l’autre raison pour laquelle je pousse IPv6…
A la fin, je présente les différents scénarios de “connexion” (plus du transfert de données). Le tout en UDP. Comme tu peux le voir, y’as tout un tas de scénarios possibles (même si STUN aide pas mal). C’est l’autre raison pour laquelle je pousse IPv6…[/quote]
Merci ! J’ai jeté un coup d’oeil et ça semble bien résumer toute la problématique. Ca va me permettre d’y voir plus clair et surement de trouver des solutions.
@Unreal :
Dis moi si je me trompe :
NAT = système permettant de diriger les paquets selon certaines règles précises.
Routeur = système gérant de façon automatique les paquets.
Pour ce qui est du mappage de port, c’est niet tu t’en doutes. A l’instar de Skype, il s’agit de mettre en place une appli user-friendly.
A propos de NAT traversal, je suis tombé sur le logiciel Hamachi, dont on peut télécharger une version (bridée) gratuite. Peut-être que ça te donnera des idées, en tout cas j’ai testé et c’est assez bluffant (cela dit mes connaissances “réseaux” sont assez limitées).
Ensuite, ce n’est pas forcément parce que tu es derrière un FW/NAT que tu ne peux pas recevoir de connexions : il suffit de mapper le port.