Discussion :

[Evorlde]

Bonjour à tous,

Nous développons actuellement un jeu et avons une architecture réseau qui fonctionne comme cela:
Les clients se connectent à un serveur en contactant le serveur sur le port X. A partir de ce moment une socket est ouvert et tout se passe bien.


Problème A:
Nous aimerions que les joueurs puissent lancer un serveur sur leur ordinateur. Une fois lancé, le serveur attend les connexions sur le port X, mais la box ne laisse pas passer les demandes de connexion.

Problème B:
Nous aimerions que les joueurs puissent discuter en audio sans avoir à passer par le serveur. Donc il nous faudrait ouvrir une connexion client à client. Et la même problème qu'au dessus, comment passer la box?

Bien sur il est toujours possible d'ouvrir les ports sur la box mais nous aimerions que le joueur n'est pas à configurer sa box car ce n'est pas à la porté de tout le monde.

J'ai vu que nous pouvions utiliser les protocoles UpNp ou encore le Hole Punching.

Ma question:
1) Comment font les jeux actuel pour résoudre ce problème et arriver a "ignorer" la box?


Merci,

Evorlde.

[Neckara]

Bonjour,

Deux solutions, soit votre logiciel arrive à communiquer avec la box pour ouvrir un port, soit il vous faut faire du TPC/UDP "hole punching".

En gros, tu as un serveur S accessible.
Ton serveur-client s et ton client c vont établir une connexion sur ton serveur S.
Tu auras donc les liens s <-> S et c <-> S.
S donne ensuite à c les coordonnées de s (ip/port).
c tente alors de se connecter sur le couple (ip/port) de s.

Le tout est que s écoute sur le même port utilisé pour communiquer avec S.
Note : il faut utiliser un flag "reuse".

J'avais réussi à faire un code avec boost, mais il ne me semble pas l'avoir vraiment testé et je ne saurais pas le retrouver.

[Evorlde]

Bonjour Neckara et merci pour ta réponse,

Nous allons utiliser le hole punching qui semble plus universel, plus sure et plus propre, toutefois j'aimerai reformuler la solution afin que tu me confirme que j'ai bien compris ou pas.

1) Nous avons un serveur joignable sur l'ip 168.40.40.40 (ip exemple) et les port 4 000 et 5 000. Le serveur est sur une machine quelque part dans le monde ce n'est pas bien important.
2) Nous avons un client qui se connecte au Serveur sur l'ip 168.40.40.40 et le port 4 000.
3) Nous avons un serveur de jeu qui tourne chez l'utilisateur (ip 170.40.40.40) et qui se connecte sur le Serveur 168.40.40.40 port 5 000.
4) Le serveur 168.40.40.40 va donner au client l'ip 170.40.40.40 et le port 5 000.
5) Le client va se connecter a l'ip 170.40.40.40 sur le port 5 000.


Questions:
A) Quand tu dit qu'il faut que le serveur "écoute" sur le port 5 000, veux tu dire que il faut que le port 5 000 soit ouvert sur la box? Ou le fait d'avoir établi une connexion socket vers 168.40.40.40 sur le port 5 000 avec le paramètre reuse suffit?
B) Quand tu dit d'utiliser le flag reuse, cela signifie lors de la création de la socket entre le serveur local et le serveur distant?

En te remerciant,

Evorlde.

[Neckara]

4) Le serveur 168.40.40.40 va donner au client l'ip 170.40.40.40 et le port 5 000.
5) Le client va se connecter a l'ip 170.40.40.40 sur le port 5 000.

Presque, le port ne sera pas 5000.
5000 correspond au port d'écoute du serveur.
Mais ton client-serveur utilisera très certainement un autre port pour se connecter au port 5000 du serveur.

En gros, tu vas avoir une communication 170.40.40.40:X vers 168.40.40.40:5000.
Où X sera un port qui changera qu'il faudra que tu récupères grâce à ta bibliothèque réseau sur ton serveur.

A) Quand tu dit qu'il faut que le serveur "écoute" sur le port 5 000, veux tu dire que il faut que le port 5 000 soit ouvert sur la box? Ou le fait d'avoir établi une connexion socket vers 168.40.40.40 sur le port 5 000 avec le paramètre reuse suffit?

En théorie, établir une connexion suffit à ouvrir le port.
Mais je ne peux pas le garantir à 100%, il se peut que la box refuse, mais cela doit être très rare.

Sinon tu peux te renseigner sur comment font les logiciels de p2p pour justement établir de telles connexions. Mais à part ouvrir un port ou faire du hole punching...

B) Quand tu dit d'utiliser le flag reuse, cela signifie lors de la création de la socket entre le serveur local et le serveur distant?

Oui.

[Evorlde]

En gros, tu vas avoir une communication 170.40.40.40:X vers 168.40.40.40:5000.
Où X sera un port qui changera qu'il faudra que tu récupères grâce à ta bibliothèque réseau sur ton serveur.

D'accord je comprends mieux la logique, je pensais à tord que le port destination serait le même en local.


Problème:
Nous avons encore un problème avec le flag reuse.

Questions:
1) S'agit il de SO_REUSEPORT?
2) Nous mettons ce flag à la création de la socket Windows pour la connexion serveur de jeu (derrière la box) vers le serveur distant. Mais devons nous également mettre ce flag lors de la création de la socket du client vers le serveur de jeu?
3) Ce flag à t'il un équivalant sous Unix?
4) Peux tu nous donner un exemple d'une création de socket avec le flag reuse?

Encore merci de ton aide,

Evorlde.

[Neckara]

1) S'agit il de SO_REUSEPORT?

Peut-être, j'utilisais boost.asio donc je n'ai pas vu le nom du flag "bas niveau".

2) Nous mettons ce flag à la création de la socket Windows pour la connexion serveur de jeu (derrière la box) vers le serveur distant. Mais devons nous également mettre ce flag lors de la création de la socket du client vers le serveur de jeu?

Non, pas la peine, il suffit juste que ton client créé une nouvelle socket pour se connecter au client-serveur.

3) Ce flag à t'il un équivalant sous Unix?

Oui.

4) Peux tu nous donner un exemple d'une création de socket avec le flag reuse?

Je crois que tu as un exemple ici : http://www.boost.org/doc/libs/1_42_0...er3/server.cpp