Discussion :

[jkalzsmu]

Bonjour,

Je suis actuellement en train de programmer un petit projet perso (un jeu) : http://sourceforge.net/projects/migoo/

Par rapport au jeu en réseaux je pense utiliser l'architecture client/serveur.
Seulement je me pose une question :

Imaginons que dans une maison il y ait une box traditionnelle faisant office de routeur.
Si 2 pc veulent jouer au jeux en réseau (et sur internet) alors ils vont utiliser le même port (coder en dur dans le jeux).
Pour pouvoir jouer, il faut dire au routeur de rediriger le port sur une adresse ip spécifique (en dur dans la configuration du routeur).
Donc logiquement le routeur va re-diriger tous les paquet que sur 1 seul des 2 ordinateurs.

J'imagine qu'on peux faire quelque chose mais je ne vois pas!

[LeGreg]

Bonjour,

Je suis actuellement en train de programmer un petit projet perso (un jeu) : http://sourceforge.net/projects/migoo/

Par rapport au jeu en réseaux je pense utiliser l'architecture client/serveur.
Seulement je me pose une question :

Imaginons que dans une maison il y ait une box traditionnelle faisant office de routeur.
Si 2 pc veulent jouer au jeux en réseau (et sur internet) alors ils vont utiliser le même port (coder en dur dans le jeux).
Pour pouvoir jouer, il faut dire au routeur de rediriger le port sur une adresse ip spécifique (en dur dans la configuration du routeur).
Donc logiquement le routeur va re-diriger tous les paquet que sur 1 seul des 2 ordinateurs.

J'imagine qu'on peux faire quelque chose mais je ne vois pas!

S'ils sont sur le même réseau ils peuvent peut-etre se parler en local (LAN) donc c'est peut-etre plus facile, pour trouver des clients en LAN, le broadcast IP doit être possible (s'ils sont sur le même sous-reseau).

Si tu ne veux pas implanter de jeu en local pour diverses raison, il y a plusieurs problèmes.

Imaginons X cherche à contacter Y. Il n'y a pas de broadcast sur Internet, donc pas moyen de contacter tout le monde pour lui demander s'il héberge un jeu. Donc deux solutions s'offrent à toi : tu crées un serveur à adresse fixe (un nom de domaine fixe suffira) qui sert de "browser", cela impose d'avoir un hébergement et de connaitre la programmation de cet hébergement (php ? perl ? cgi en C compilé ? asp ?), définir ton protocole (un client enregistre un jeu en donnant son couple IP/port, un client obtient la liste des jeux créés avec leur couple IP/port). Si pas de browser il faut que chaque joueur se contacte directement et s'envoie ses informations de connection (facile s'ils sont dans la même piece ou peuvent se téléphoner etc..).

Problème : un couple IP/port tout seul ne sert à rien si les deux ordinateurs sont derrière le routeur. Il faut que le routeur ait été configuré pour rediriger certains ports vers la machine hote/serveur. Par exemple port 666 de ton adresse ip publique renvoie sur ordinateur babacool1 (tu peux meme potentiellement avoir un port différent sur babacool1 puisque seul le routeur voit ce port). Donc ton utilisateur doit être suffisamment capable pour modifier la config de son routeur, et etre sûr que le firewall interne ne bloque pas les ports d'entrée. Ou bien utiliser l'approche Universal plug and play qui te permet depuis l'intérieur de ton programme de modifier la configuration de ton routeur et en particulier le forwarding de ports. ça c'est pour le serveur.
Quid du client ? le client va se contacter à l'adresse donnée par le browser (ou communiquée en privé par téléphone, voie orale, email, messaging etc..) sur le port donné. Le fait qu'il soit derrière un routeur/firewall n'est pas forcément un probleme (sauf si le firewall est très agressif sur les connections sortantes, style zonealarm en config par défaut, mais bon c'est indépendant) à partir du moment ou tu es en mode "connecté". Le mode connecté maintient une "connection" entre le client sur addresse source/port source et le serveur sur address dest/port dest. Le routeur et firewall sont suffisamment intelligents pour détecter que l'on est en mode connecté et donc pas besoin de forwarder de port vers la source (il faut avoir le forwarding pour la dest !). De même si l'address source et addresse dest sont les mêmes le port est forcément différent (port source choisi aléatoirement à la connection) ce qui fait que le routeur sait quoi faire. Cela serait plus problèmatique si tu étais en mode non connecté (datagrammes UDP), dans ce cas, les deux ordinateurs doivent avoir le forwarding de port configuré (typique des programmes peer to peer). UDP n'est pas forcément (plus) très utilisé mais n'est pas à forcément à ignorer pour certains avantages (mode de communication non bloquant mais arrivée des paquets désordonnés).

Si le forwarding etc te semble compliquée ou inaccessible (le routeur n'est pas upnp ou il est désactivé pour raison de sécurité ou la config est gérée par un administrateur qui ne veut pas autoriser les jeux), la solution finale on va dire est de faire appel à un serveur tiers contactable directement. Donc il faut maintenir une présence internet permanente (ou le temps d'une partie) auquel deux ordis (ou plus) peuvent s'adresser en mode "connecté" et le serveur va rendre le service de passer les paquets du client 1 au client 2. Cela rajoute du temps de latence et le serveur tiers doit avoir suffisamment de bande passante pour accommoder tous les gens jouant au jeu en même temps. Mais c'est par exemple le mode utilisé pour plein de serveurs dédiés (ou les MMORPGs). Le serveur pouvant rendre d'autres services (faire tourner la logique du jeu, heberger les sauvegardes, le chat, aider au matchmaking etc..)

Il y a des librairies exisantes (commerciales ou pas) qui je pense peuvent t'aider à supporter toutes ces options (gne, opentnl, probablement d'autres).

LeGreg

[jkalzsmu]

Merci LeGreg pour cette réponse bien fournie !

Alors effectivement, je pensais utiliser le mode non connecté UDP parce que c'est plus rapide et que l'ordre des paquets n'as pas vraiment d'importance.
Mais si tu me dis qu'en mode connecté TCP, il n'y as pas de problèmes de configuration de xxxBox où routeur alors là, je préfére de loin la solution non connectée !

Parce que je vois mal les gens configurer un routeur juste parce qu'ils ont envie de jouer au jeux. Déjà s'ils ont envie d'y jouer, ça sera pas mal !

Sinon au niveau de la configuration, je pense utiliser un serveur tiers contactable directement qui fera tourner la logique du jeu (gestion des collisions, bonus/malus, etc ...).
D'ailleurs je pense même qu'une bonne base mysql pour héberger la liste des parties devrait faire l'affaire non?

Pour ce qui est de l'utilisation d'une librairie, je vais plutôt essayer de coder tout ça à la main. La partie réseaux est importante mais j'pense pas avoir besoin d'une librairie juste pour faire une connection TCP/IP.

Merci encore,

Thomas

[nouknouk]

salut,

Alors effectivement, je pensais utiliser le mode non connecté UDP parce que c'est plus rapide et que l'ordre des paquets n'as pas vraiment d'importance.

UDP n'est absolument pas plus rapide: UDP ne gère simplement ni l'intégrité des paquets ni leur perte, ni leur ordonnancement. Ce qui fait que si un paquet est perdu/erronné/désordonné, la pile du protocole ne "perdra" pas de temps à le redemander.
Mais attention: si UDP est bien utile pour certaines applis critiques en termes de 'temps réel', il est bien plus ardu de développer une application au dessus.
Non pas parce que la technique entre une socket UDP et une TCP est différente, mais surtout parce qu'il va te falloir gérer TOUS (et j'insiste) les cas d'erreurs: paquets complètement erronés, données flasifiés, paquets perdus, ... Et c'est bien moins simple que ce que visiblement tu penses.

Mais si tu me dis qu'en mode connecté TCP, il n'y as pas de problèmes de configuration de xxxBox où routeur alors là, je préfére de loin la solution non connectée !
Parce que je vois mal les gens configurer un routeur juste parce qu'ils ont envie de jouer au jeux. Déjà s'ils ont envie d'y jouer, ça sera pas mal !

Pour une application ou plusieurs clients communiquent entre eux, et où on veut pouvoir se connecter derrière un routeur sans avoir à tripoter les ports, il n'y a définitivement qu'une solution : le TCP ET un serveur TCP qui servira au minimum de relais.
Toutes les autres (UDP, TCP en peer-to-peer), etc... ne sont pas viables.

Sinon au niveau de la configuration, je pense utiliser un serveur tiers contactable directement qui fera tourner la logique du jeu (gestion des collisions, bonus/malus, etc ...).
D'ailleurs je pense même qu'une bonne base mysql pour héberger la liste des parties devrait faire l'affaire non?

Un serveur ne peut pas se résumer à une simple base MySQL que les clients contacteront pour s'inscrire si tu pars dans la logique 'zéro configuration de port'. Les clients devront maintenir une connection TCP pour échanger des données.

Il te faut donc au minimum un programme qui tourne sur le serveur pour accepter les connections TCP, les maintenir et permettre le relayage de paquets entre plusieurs clients.

Aucune techno 'web' ne te permettra de faire cela (comprendre un hébergeur de site web uniquement, genre les hébergeurs gratuits comme les pages perso Free, etc...).
Il te faut nécessairement un serveur dédié. Cela peut se trouver maintenant pour relativement peu cher. Le plus bas prix que je connaisse c'est OVH et son VPS à 9,99€ par mois.

Il y a déjà eu plusieurs topics sur le même sujet, mais il faut plutôt fouiller dans le forum développement réseaux. Notamment ce topic (auquel j'ai participé).

PS: l'UPnp est effectivement la solution pour se passer de la configuration manuelle de ports. Mais la majorité des routeurs de monsieur tout-le-monde (genre Freebox, NeufBox, ...) ne l'a pas (ou pas activé). Donc autant dire que la solution n'est pas viable si ton programme s'adresse au grand public. Sinon, il y aura également IPv6 qui devrait régler pas mal de soucis, mais c'est pas pour tout de suite...

[jkalzsmu]

En me relisant je m'apperçoit que je me suis mal exprimé.
Je ne pensais pas faire un serveur avec une base mysql pour gérer le jeu, ce que je pense faire c'est simplement héberger la liste des partie sur un serveur mysql.

Pour ce qui est du serveur, je ne peux pas me permettre d'en avoir 1 dédié. Il faut qu'un des joueurs joue le rôle de serveur. Auquel cas si j'ai bien compris il devra ouvrir ses port dans la configuration de son routeur, mais pas les autres clients.
Dès lors qu'il a un serveur qui tourne, il envoie une requette sql sur le serveur mysql pour lui dire qu'un serveur est disponible.
Ainsi, si je suis simple client, je peux récupérer la liste des parties sur internet et rejoindre le serveur :-)

[nouknouk]

^^ c'est exactement ça.

Effectivement, c'est une solution techniquement acceptable, ou ton serveur de Bdd jouera simplement le rôle de fournisseur d'adresse IP de serveurs dispos.

Mais le problème majeur est que si aucun joueur n'a de port ouvert, aucun serveur ne tournera. Et c'est malheureusement de plus en plus courant d'avoir des connexions derrière un NAT. Je dirais même que ça doit probablement être la grosse majorité des utilisateurs (multiplication des ADSLbox, de l'utilisation domestique du WiFi qui présuppose un point d'accès donc du NAT, ...).

Une autre solution pas dépensière: tu te montes une sorte de mini serveur perso en récupérant quelques pièces informatiques par-ci par là. Pas besoin de grand chose:
- une carte mère, un proc (même un anémique)
- une carte réseau
- une alim
- un linux sur clef USB

Tu peux t'en sortir avec du matos d'occasion pour moins de 50€ sans souci. Tu l'installes chez toi, sur ta connexion ADSL perso. Bien entendu le serveur sera limité par la débit en upload de ta connexion ADSL (typiquement 1Mbits/sec, soit 128ko/sec). Mais dans un premier temps, ça peut largement suffire.

A noter également qu'il existe une entreprise qui fournit des serveurs de sockets : Your-Socket.com. Mais leur prix (8€ pour la version de base) me semble exagéré par rapport au service rendu, surtout comparé aux offres 'discount' d'OVH.

[jkalzsmu]

Je crois que je vais rester sur ma première idée quand même.
Parce que le serveur doit faire pas mal de calculs pour le jeu, donc un serveur perso ne pourra pas héberger plusieurs parties simultanément.
Et puis sa évite de bouffer la connections internet de papa/maman et du courrant :-)

[Pat_AfterMoon]

Bonjour,

Il y a une autre possibilité : utiliser un VPN. Il en existe qui sont très simplifiés et dédiés aux jeux en réseau.

J'ai déjà utilisé Hamachi et Wippien.

Cela ne nécessite aucun boulot pour le développeur du jeu, et coté client c'est plutôt simple. Cela peut même être utilisé comme un bon tchat pour se réunir avant de faire une partie (j'ai une petite préférence pour Wippien, qui est libre et compatible Jabber).

Si on regarde sous le capot, cela revient à utiliser un serveur relais, mais le service est fourni dans les 2 cas (gratuit et sans limite pour Wippien).

Pour avoir testé coopordie, mon "mod" Quake2 (UDP), avec Wippien, le ping est en moyenne augmenté de 10ms par rapport à une liaison directe, ce qui reste raisonnable.