Version imprimable
Bonjour,
J'ai développé un serveur en C++ et je voudrais pouvoir y communiquer avec un client distant cependant il faut que j'ouvre le port du serveur sur l’extérieur (port forwarding) mais je n'ai aucune idée de comment faire en C++.
Sur internet je ne trouve que des tutos pour ouvrir un port manuellement, moi je voudrais le faire automatiquement de la même façon que font les logiciels P2P.
Pouvez vous éclairer svp? Merci d'avance ;)
PS: Je suis sous Windows
Bonjour,
Je présume que ton serveur se trouve derrière une box internet et que tu dois rediriger manuellement des ports de la box vers des ports de ton serveur pour pouvoir accéder à ton serveur ?
Or tu souhaiterais pouvoir rediriger automatiquement les ports de ta box ?
Si oui, la solution serait de faire du "hole punching".
A moins que tu ne parles d'autoriser à ton serveur à ouvrir le port car il est bloqué par défaut par le parefeux Windows ?
Merci pour ta réponse ;)
Je ne connaissais pas le hole punching, j'ai recherché ce que c'était et j'ai pu voir que c'était pas mal utilisé en réseau pour le P2P, VoIP, visioconférence, etc... Donc cette solution m’intéresse beaucoup et je vais me renseigner sur son fonctionnement :ccool:
Si tu utilises boost, j'ai un code presque tout fait (moyennant quelques modifications et améliorations selon tes besoins).
Je veux bien le code si tu l'as stp ;)
Je te le donne en pièce jointe.
Si jamais tu corriges des bugs ou fait des modifications, fais-en moi part ;)
Je n'ai pas eu le temps d'ajouter les commentaires.
Pour faire simple, j'ai trois postes :
- Serveur ;
- Hote ;
- Client ;
L’hôte se connecte au serveur et lui donne une clée ( 8 octets). Le serveur associe alors à la clée l'ip et le port de l’hôte.
Le client se connecte au serveur et récupère l'ip et le port de l'hôte grâce à la clé.
Puis il se connecte à l'hôte grâce à l'ip et au port donné.
Si cela marche, c'est parce que côté hôte, on utilise reuse pour écouter le même port que pour le socket de communication avec le serveur en attente de connexion entrante. Et comme un socket discute avec le serveur, la box redirige automatiquement un de ses ports vers le port de l'hôte.
Merci :ccool:
Pas de problème ;)Citation:
Envoyé par Neckara
Salut
Les logiciels de P2P ne font rien automatiquement, il faut quand même rediriger manuellement au moins un port sur la box ! Ce qui arrive sur certaines box, c'est que des plages de ports entières soient redirigées, ou alors la box n'est pas configurée en NAT parce qu'un seul appareil est branché, et dans ce cas ça marche tout seul.Citation:
Envoyé par debian21
Ton exécutable doit aussi avoir le droit d'ouvrir des ports sans que Windows ne l'en empêche. Les logiciels de P2P peuvent le faire car ils obtiennent ces droits à l'installation, qui nécessite des droits administrateur.
Le hole punching est une autre histoire. Il va permettre la redirection automatique de ports, mais il faut bien que le client puisse accéder au serveur au moins au début pour récupérer la clé, et pour ça il lui faut un port que le serveur écoute et qui a été redirigé à l'origine.
@jblecanard : Cela va dépendre de la structure de ton réseau P2P, mais P2P n'exclus pas le fait qu'on puisse avoir un petit serveur pour certaines tâches.
Certes oui ! Mais qui dit serveur dit... port pour pouvoir se connecter dessus, non ?Citation:
Envoyé par Neckara
UPNP, non ? On doit pouvoir trouver des bibliothèques pour ça (si je ne me plante pas, il va simplement falloir annoncer ton service, et le routeur, s’il est configuré pour, créera la route correspondante)
Après, c’est une faille de sécurité, mais si c’est ce que tu veux faire…
Mhhh... Concernant le p2p, tu as Openp2p que je viens de voir, qui est une bibliotheque qui est un wrapper de boost asio, fait pour le P2P.
et l'UPNP je connais mais, je ne pense pas que ça soit l'utilisation adéquate (je me trompe (?)) mais, comme Neckara la précisé la technique à utiliser est le hole punching. D'ailleurs c'est plus utilisé pour de l'UDP, et beaucoup moins pour du TCP.
L’upnp sert à beaucoup de trucs (encore plus avec l’upnpav, qui est en fait très différent), mais notamment à ça : configurer automatiquement les routes reverse nat.
Donc je pense que c’est à creuser (il me semble bien que c’est ce qu’utilisent la plupart des logiciels de p2p). Le hole punching, si les deux machines sont natées, c’est mort.
Pour le hole punching, il suffit juste d'avoir une troisième machine, et on pourra trouver des serveurs gratuits proposant un tel service dans quelques semaines.