Discussion :

[leghola]

Bonjour,

Le titre veut a la fois tout dire et rien dire donc je vais tenter de m'expliquer un peu plus en détail.
En premier lieu, déjà, merci de me lire

Je souhaite créer un réseau un peu spécifique entre des postes clients au travers d'internet. J'ai déjà effectué des réseaux standards Client/Server au travers de ma Box en créant des règles NAT mais ce que je souhaite faire c'est bien de connecter plusieurs clients entre eux et les faire discuter ensemble sans passer par un serveur-relais.

J'ai réfléchi au PeerToPeer mais je ne trouve pas assez de doc dessus, j'ai découverte aussi la Perforation UDP qui me semble appropriée mais la aussi la documentation me manque.

Dans ma théorie, un serveur existe et se trouve etre défini comme serveur d'authentification. Chaque client a la connexion au serveur reçoit une liste des autres clients afin de pouvoir les contacter.
Le problème est : comment contacter un client au travers d'une box sans avoir besoin de faire de reroutage ?!

POur finir, j'ai récement découvert cette bibliothèque...
http://code.google.com/p/lidgren-network-gen3/

En espérant avoir été clair, merci d'avance

Nico.

[gangsoleil]

Le problème est : comment contacter un client au travers d'une box sans avoir besoin de faire de reroutage ?

Reponse simple : tu ne peux pas.

Reponse plus detaillee : ton paquet arrive a la box. Il est donc destine a la box (seule adresse IP publique, les adresses IP "internes" etant accessibles via du NAT), qui le regarde (avec bienveillance). Deux possibilites :

• Le port XX de reception du paquet est redirige vers le port YY de la machine A --> le paquet va etre route vers cette machine
• Il n'existe pas de regle de routage pour ce port --> le paquet est jete.

[leghola]

Merci pour cette réponse, c'est celle que j'ai dans la tête moi aussi mais il y a des techniques alors dans le PeerToPeer que je ne comprends pas alors...

Le PeerToPeer est bien une technologie qui permets de transferer des données entre des postes "clients" sans avoir recours a une transition par un serveur. On dit d'ailleurs que les clients deviennent des serveurs. Par conséquent, un client doit pouvoir être contacté par un autre client non ?

Maintenant d'un point de vue technique, voici une idée (désolé si c'est une grande débilité mais j'ai tendance a exposer mes idées les plus saugrenues possibles et parfois j'arrive a interloquer les gens qui savent ) :

-Client A se connecte a un serveur via UDP, le routeur type BOX créé donc dynamiquement une règle de routage pour UDP.

- Le Serveur stocke cette connexion et ses paramètres.

- Client B se connecte au serveur, le serveur envoie alors les infos de connection du client A au client B pour que ce dernier puisse discuter avec SANS passer par le serveur.
Le client B passe donc par la meme regle NAT que le serveur et peut contacter le client A.

-> Grosse bétise ?

A+
Nico

[gangsoleil]

Bonjour,

Lorsque tu fais du P2P derriere un routeur (que sont les box actuelles), tu es oblige de router un port entrant du routeur vers ta machine (afin que les autres puissent se connecter justement).

Lorsque tu etablis une connexion sortante, le routeur n'accepte pas les connexions entrantes sur cette connexion. Il n'accepte que les reponses aux requetes qui ont ete emises via cette connexion. Et non, il n'est pas possible de faire passer une requete pour une reponse.

Pour avoir des infos sur les principes de fonctionnement du P2P, tu peux lire cet article.

[leghola]

Merci encore de cette réponse.
J'ai été effectivement voir cet article très bien écrit avant de venir poster ici.

Mais c'est justement cet article qui m'a titillé et surtout la partie attribuée aux Super-Peers qui dit

Principes de Kazaa
Un nouvel utilisateur doit ouvrir un compte, déclarer ses répertoires de fichiers partagés. En fonction de sa bande passante, le logiciel décidera si le client est ou non un super-peer

Si je comprends bien cette phrase, tout poste client peut devenir super-peer et donc il peut être contacté par d'autres clients sans rien avoir a faire d'autre...

Maintenant imaginons qu'un client A se connecte, il est considéré comme Super Peer par le serveur et se voit attribué des clients B,C,D. Le serveur pourrait il envoyer une info au client A qui pourrait ensuite le relayer aux clients B,C,D directement sans repasser par le serveur ?! Je ne parle plus d'un système de requête qui demande une réponse en retour mais juste un envoi d'un message a d'autres clients.

Merci,
A+
Nico

[gangsoleil]

Bonjour,

Le fait d'avoir un serveur oblige simplement a faire de la redirection de port de ta box vers ta machine, c'est tout. Il n'y a rien de complique la dedans, et les tutoriels pour le faire sont extremement nombreux (ne serait-ce que parce que certains jeux utilisent du P2P pour les updates).

Je ne vois pas ton probleme en fait : lorsque tu deviens un pair du reseau, tu ouvres un port en reception, et voila.

[leghola]

Bonjour,

Effectivement, la redirection de port n'a rien de sorcier. Surtout avec les box d'aujourd'hui ou les créations de regles NAT sont quasi automatisées (rien a voir avec mon firewall squidguard sous fedora.... ^^)

Maintenant, je vais essayer d'être plus clair car je pense mal m'exprimer.
Il est évident et très simple si on héberge un petit serveur chez nous de paramétrer une redirection de port sur notre machine qui possède l'application serveur.


1. les connexions

Je suis le SERVEUR et j'ai tout paramétré correctement pour être joignable sur le port 12345.
Un CLIENT A se connecte au SERVEUR sur le port 12345. La box du client A créé alors une règle dynamique et aléatoire pour cette connexion et décide d'utiliser le port 2222.

Nous avons donc le CLIENT A qui a ouvert le port 2222 et se connecte au SERVEUR sur le port 12345.

Le CLIENT B arrive et se connecte au SERVEUR sur le port 12345. Aucun probleme le SERVEUR accepte. Le CLIENT B a lui de son coté ouvert un port aléatoire par exemple 3333.

2. le simili peer to peer

Maintenant le serveur au moment de la connexion estime suivant un calcul de bande passante si un CLIENT peut devenir "super-peer". Il teste et voit que CLIENT A est dans ce cas mais pas CLIENT B.

Quand CLIENT B se connecte, SERVEUR estime que CLIENT B ne peut pas être "SuperPeer" et donc lui affecte un "superpeer", ici, CLIENT A et lui envoie son IP et PORT (ici 2222).

CLIENT B fait un appel a CLIENT A sur le port 2222 pour se connecter. CLIENT A réponds (car le port est déjà ouvert et natté dynamiquement) => CLIENT B est connecté a CLIENT A sans passer par le serveur.

3. le cheminement des messages

Le SERVEUR doit envoyer un message a tous les clients. Il l'envoie aux Supers-peers qui ont la charge de le re transférer a leurs "enfants".
Dans ce cas, SERVEUR envoie un message a CLIENT A qui est en charge de l'envoyer a CLIENT B.

D'un autre coté, CLIENT B doit envoyer une information. Il l'envoie alors a son "parent" CLIENT A qui est en charge de le retransférer au SERVEUR qui le renverra a son tour a tous les autres SuperPeers.


Ma conception est elle plus claire ?
Et ma question est : ce genre de concept est il possible en pratique (en théorie tout est toujours tres beau....)

A+
Nico

[gangsoleil]

Je pense que ce sera plus clair avec les mots en gras

1. les connexions

Je suis le SERVEUR et j'ai tout paramétré correctement pour être joignable sur le port entrant 12345.
Un CLIENT A se connecte au SERVEUR sur le port 12345. La box du client A créé alors une règle dynamique et aléatoire pour cette connexion et décide d'utiliser le port sortant 2222.
Nous avons donc le CLIENT A qui a ouvert le port sortant 2222 et se connecte au SERVEUR sur le port entrant 12345.

Le CLIENT B arrive et se connecte au SERVEUR sur le port entrant 12345. Aucun probleme le SERVEUR accepte. Le CLIENT B a lui de son coté ouvert un port aléatoire sortant par exemple 3333.

CLIENT B fait un appel a CLIENT A sur le port 2222 pour se connecter.
CLIENT A réponds (car le port est déjà ouvert et natté dynamiquement)

Justement non. Le port 2222 est un port sortant, qui ne peut pas accepter de connexions entrantes. Pour que B se connecte, il faut que A ait ouvert un port entrant sur sa box, et bien sur dans son logiciel.

Le SERVEUR doit envoyer un message a tous les clients. Il l'envoie aux Supers-peers qui ont la charge de le re transférer a leurs "enfants".
Dans ce cas, SERVEUR envoie un message a CLIENT A qui est en charge de l'envoyer a CLIENT B.

Le serveur repond a A sur le port 2222. A peut alors traiter la reponse, et envoyer l'information a B. Cela va ouvrir un autre port sortant sur A.

Et ainsi de suite.

Est-ce que c'est plus clair comme ca ?

[leghola]

Merci pour ces éclaircissements.
Je vais continuer malgré tout (oui je suis un peu tête de mule parfois) et je donnerai les résultats de mes tests.

Actuellement, en LAN, ma technique fonctionne :
- SERVEUR Lancé sur 1.1.1.1:1111
- CLIENT A se connecte a SERVEUR sur 1.1.1.1:1111 en utilisant son IP 1.1.1.2:2222
- CLIENT B se connecte sur CLIENT A sur 1.1.1.2:2222

Si SERVEUR envoie un message, seul CLIENT A le recoit.
Si CLIENT A envoie un message, seul SERVEUR le recoit.
Si CLIENT B envoie un message, seul CLIENT A le recoit.

A+
Nico

[gangsoleil]

Actuellement, en LAN, ma technique fonctionne

En LAN, sans vrai firewall, il est normal que tu n'aies pas de soucis.

Le soucis vient du routeur : les paquets ne sont pas a destination de ton PC, mais du routeur. Donc s'il ne sait pas ou les router, il ne peut rien faire.

Vois un peu ca comme si le facteur deposait tout le courrier d'un immeuble chez le gardien : s'il y a une lettre pour leghola, il sait quoi en faire. S'il y a une lettre sans nom, il ne sait pas quoi en faire.