Discussion :

[odsen.s]

Bonjour à tous,

Je travaille actuellement sur un projet dont le but est de réaliser un jeu du style "shoot'm'up" en réseau, en utilisant Java. Je viens de lire le tutoriel sur la gestion des sockets en Java (http://humbert-florent.developpez.co...reseau/avance/), qui ne m'a pas posé de problèmes.

Ma question portait plus sur la façon d'organiser le réseau pour mon application (c'est en effet ma première application réseau) : il n'y aura que 2 joueurs, qui s'échangeront des informations sur le nombre d'ennemis abattus toutes les n secondes. Faut-il mieux créer pour chaque joueur un socket client et un socket serveur, ou une solution avec un joueur serveur et un joueur client serait-elle suffisante ? Quelle solution apparaît la plus adaptée ? En existe-t-il d'autres ?

Par avance, merci pour vos conseils.

[nouknouk]

Salut,

la solution avec deux socket (1 client, 1 serveur) pour chaque client est inutile: à partir du moment où une connexion est établie, tu peux sans aucun souci échanger des informations dans les deux sens.
Donc mieux vaut utiliser une connexion unique pleinement (ie dans les deux sens), plutôt que deux conexions à moitié.

Par contre j'attire ton attention sur une architecture en réseau de type Peer2Peer (au delà des mules, c'est aussi le nom quand deux 'clients', se connectent directement entre eux pour échanger les infos): le gros problème est que dans la majorité des cas, lesdits clients désirent jouer de chez eux, typiquement depuis leur ordinateur connecté à leur box ADSL ... qui fait du NAT.

Ces clients ont des adresses IP sur leur réseau local (ie. derrère leur box). C'est parfait quand le client veut initier des connexions vers l'extérieur, mais hors cas spécifiques (*), aucun de tes deux clients ne pourra jouer le rôle de 'serveur' car sa box refusera les connexions entrantes. Attention: je ne dis pas que c'est impossible, mais que tu prends le risque de rebuter plus d'un joueur potentiel s'il doit manuellement configurer une redirection de port sur sa box ADSL.

C'est une des raisons (**) qui fait que dans la majorité des cas de jeux en réseau, on utilise une architecture réseau avec un serveur intermédiaire (qui lui a une IP publique et accepte sans souci les connexions venant de l'extérieur).
Chaque client se connecte au serveur et dialogue avec lui. Quand un client a une info à faire passer à l'autre client, il l'envoie au serveur qui se charge alors de transmettre le message à l'autre client.

A toi de voir.



(*) redirection explicite de ports, usage de l'uPnp, ... qui ne sont ni présentes à tous les coups, ni simples à mettre en oeuvre pour les profanes.

(**) l'autre raison majeure étant de pouvoir détecter et éviter les client hackés pour tricher. Le serveur central jouant alors le rôle "d'arbitre" pendant la partie en vérifiant la 'cohérence' des affirmations de chaque joueur.

[odsen.s]

Merci pour ces infos,
je pense que je vais me tourner vers une connexion P2P,
ça n'est pas vraiment important si le jeu ne fonctionne que sur
un réseau local, c'est un projet pour l'école.

Merci bien dans tous les cas !