Discussion :

[masterix59]

Bonjour à tous,

Voilà mon soucis j'ai un projet à réaliser une bataille navale en ce qui concerne son execution pas de soucis j'ai réussi a coder le programme reste un soucis, j'aimerais maintenant pouvoir executer ce jeu en reseau

En gros voilà mon idée grâce aux deux adresse IP des 2 ordinateurs j'aimerais pouvoir lancer sur les deux postes en meme temps le programme puis ensuite pouvoir jouer chacun son tour en prenant en compte les différents coup executer au fur et à mesure !

J'en demande peut être beaucoup pour le moment j'en suis à la partie recherche d'information qui n'a pas donner grand chose avec mon ami google...
Quelqu'un pourrais t'il me donner quelque conseil de réalisation ? J'aimerais savoir si cette partie est réalisable concretement ?

Merci d'avance pour vos réponses

[nuFox]

Je ne suis pas un pro de la programmation ...

Mais il serait peut etre plus facile d'envisager la solution ou tu aurais un serveur ... et deux clients ...

Tu lances le serveur et les clients viennent se connecter dessus ...

[Emmanuel Delahaye]

Bonjour à tous,

Voilà mon soucis j'ai un projet à réaliser une bataille navale en ce qui concerne son execution pas de soucis j'ai réussi a coder le programme reste un soucis, j'aimerais maintenant pouvoir executer ce jeu en reseau

En gros voilà mon idée grâce aux deux adresse IP des 2 ordinateurs j'aimerais pouvoir lancer sur les deux postes en meme temps le programme puis ensuite pouvoir jouer chacun son tour en prenant en compte les différents coup executer au fur et à mesure !

J'en demande peut être beaucoup pour le moment j'en suis à la partie recherche d'information qui n'a pas donner grand chose avec mon ami google...
Quelqu'un pourrais t'il me donner quelque conseil de réalisation ? J'aimerais savoir si cette partie est réalisable concretement ?

Merci d'avance pour vos réponses

Les sockets ne fonctionnent que selon un seul principe : client/serveur. Pour faire une application point à point, il faut donc au minimum

• un serveur
• un client

il n'y a pas le choix. Mais ce n'est pas forcément pratique, car les joueurs sont plutôt des 'clients' (pas de hiérarchie)

L'usage est donc d'utiliser un serveur qui ne sert qu'à établir la connexion entre les 2 clients

Client A <-> Serveur <-> Client B

Nota. Le serveur peut être n'importe où du moment qu'il est accessible, y compris sur une des machines 'clientes'.

Une fois la connexion établie, l'échange de données client/client se fait (via le serveur qui ne fait que relayer, (un peu comme un routeur)

Cette architecture permet des évolutions intéressantes

• Authentification à la connexion (login/mot de passe)
• Logs
• Téléchargement des jeux...
• Enregistrement des parties, des scores
• Plusieurs parties simultanées (2 joueurs)
• Jeux multi-joueurs
• etc.

Nota le serveur n'est pas spécialisé sur tel ou tel jeu. Il fait la mise en relation, c'est tout.

[corrector]

Les sockets ne fonctionnent que selon un seul principe : client/serveur.

Tu veux dire : les sockets ayant un "type" connecté (SOCK_STREAM et SOCK_SEQPACKET).

Pour faire une application point à point, il faut donc au minimum

• un serveur
• un client

il n'y a pas le choix. Mais ce n'est pas forcément pratique, car les joueurs sont plutôt des 'clients' (pas de hiérarchie)

Pourquoi pas de hiérarchie? Un premier joueur démarre un serveur, définit les paramètres (vitesse, niveau de jeu, terrain...), et invite les autres joueurs en indiquant l'adresse du serveur. Il y a déjà une asymétrie.

L'usage est donc d'utiliser un serveur qui ne sert qu'à établir la connexion entre les 2 clients

Client A <-> Serveur <-> Client B

Ça permet de connecter des joueurs qui ne se connaissent pas.

Si par contre ils se connaissent, voir sont dans la même pièce, ça me semble overkill.

Nota. Le serveur peut être n'importe où du moment qu'il est accessible, y compris sur une des machines 'clientes'.

Pourquoi distinguer le serveur du programme joueur "client"?

(Si le joueur veut partir avant la fin de la partie, il suffit que le programme se daemonise et l'utilisateur peut se déloger.)

Une fois la connexion établie, l'échange de données client/client se fait (via le serveur qui ne fait que relayer, (un peu comme un routeur)

Pour pouvoir se connecter à un joueur NATé (vive IPv6)/derrière un "pare-feu" interdisant les connections entrantes (ce qui montre l'inanité de ces "pares-feu")?

Cette architecture permet des évolutions intéressantes

• Jeux multi-joueurs

Les parties à plus de joueurs ne sont pas possibles avec l'architecture simplifiée?

Nota le serveur n'est pas spécialisé sur tel ou tel jeu. Il fait la mise en relation, c'est tout.

Tu veux dire que le serveur ne fait que le routage, sans interprétation du flux?

[Emmanuel Delahaye]

Tu veux dire : les sockets ayant un "type" connecté (SOCK_STREAM et SOCK_SEQPACKET).

Je ne suis pas expert en sockets, mais il me semble que ça concerne tous les modes.

Pourquoi pas de hiérarchie? Un premier joueur démarre un serveur, définit les paramètres (vitesse, niveau de jeu, terrain...), et invite les autres joueurs en indiquant l'adresse du serveur. Il y a déjà une asymétrie.

Oui, il y a une asymétrie dans l'application, mais pas dans l'architecture.

Ça permet de connecter des joueurs qui ne se connaissent pas.

Si par contre ils se connaissent, voir sont dans la même pièce, ça me semble overkill.

Je ne pense pas qu'on puisse faire autrement, à part simplifier le processus de connexion.

Pourquoi distinguer le serveur du programme joueur "client"?

A ma connaissance, une application socket ne peut pas être à la fois serveur et cliente...

(Si le joueur veut partir avant la fin de la partie, il suffit que le programme se daemonise et l'utilisateur peut se déloger.)

Pourquoi pas... Je ne connais pas ça...

Les parties à plus de joueurs ne sont pas possibles avec l'architecture simplifiée?

Si tu parles de l'architecture 'point à point', par définition, c'est entre 2 utilisateurs.

Tu veux dire que le serveur ne fait que le routage, sans interprétation du flux?

En mode point à point (2 joueurs), oui. Enfin rien n'empêche d'en faire plus, mais ce n'est pas indispensable.

En mode multijoueurs, non, puisqu'il faut une 'entité indépendante' qui ait la 'vision globale du jeu', et pour ça, une application située sur le serveur est la mieux placée.

[corrector]

Je ne suis pas expert en sockets, mais il me semble que ça concerne tous les modes.

Qu'est-ce que tu appelles un client et un serveur en mode datagramme?

Je ne pense pas qu'on puisse faire autrement, à part simplifier le processus de connexion.

Comme je l'ai dis : un premier joueur démarre le jeu en mode serveur, il définit les paramètres (terrain, niveau), comme s'il jouait seul contre l'IA du jeu, il indique aux autres joueurs l'adresse du serveur, chacun d'eux démarre le jeu en mode client, en indiquant l'adresse du serveur de jeu.

Le joueur qui a démarré le serveur joue comme les autres, sauf qu'il n'est pas connecté par une socket au serveur puisque c'est le même processus (ayant une latence moins importante, peut-être que cela lui donne même un petit avantage!).

Après, on peut faire des variantes :

• le serveur seul voit l'état complet de la partie, il transmet aux clients seulement les informations dont ils ont besoin au fur et à mesure
• le serveur transmet toutes les actions de tous les joueurs à tous les autres, chaque processus reconstitue l'état du jeu (il faut que les transitions soient strictement déterministes)

On peut aussi envisager une variante où les programmes communiquent en multicast, il n'y a alors plus d'asymétrie après le début de la partie.

En mode multijoueurs, non, puisqu'il faut une 'entité indépendante' qui ait la 'vision globale du jeu', et pour ça, une application située sur le serveur est la mieux placée.

Je pensais qu'en général chaque client avait une vision globale du jeu. (Ça doit dépendre du type de jeu.)

[Emmanuel Delahaye]

Qu'est-ce que tu appelles un client et un serveur en mode datagramme?

J'avoue avoir peu d'expérience sur le mode non connecté (datagramme), mais il me semble sur sur le serveur on exécute un bind() avec un numéro de port et un champ d'adresse IP.

[corrector]

J'avoue avoir peu d'expérience sur le mode non connecté (datagramme), mais il me semble sur sur le serveur on exécute un bind() avec un numéro de port et un champ d'adresse IP.

C'est ta définition d'un serveur UDP?

Et un client UDP doit être défini par opposition à un serveur UDP : un client UDP n'est pas un serveur, il communique avec un serveur UDP?

Effectivement, pour écouter le port UDP loc_port (programme P) :

• créer une socket UDP s avec socket (PF_INET, SOCK_DGRAM, 0)
• initialiser une adresse loc (sockaddr_in) à 0.0.0.0:loc_port
• lier s à loc avec bind, ce qui met la socket en écoute
• lire les datagrammes sur s avec recvfrom, ou recv, ou read

P est un "serveur".

Et pour envoyer un paquet UDP à d_ip:d_port (programme A) :

• créer une socket UDP s avec socket (PF_INET, SOCK_DGRAM, 0)
• initialiser une adresse dest (sockaddr_in) à d_ip:d_port
• utiliser sendto sur la socket s avec l'adresse dest
• (ou bien : connect()er s à l'adresse dest, puis utiliser write ou send, ça revient au même)

(Ici sendto a pour effet de lier un port local à la socket.)

A est un "client".

Pour envoyer un paquet UDP à d_ip:d_port depuis un port spécifique, loc_port (programme A') :

• créer une socket UDP s
• initialiser une adresse dest à d_ip:d_port
• initialiser une adresse loc à 0.0.0.0:loc_port
• lier s à loc avec bind (ce qui met la socket en écoute, mais ce n'est pas le but)
• utiliser sendto sur la socket s avec l'adresse dest

Ce programme A' est-il un "client"? En tout cas, il communique avec un serveur, mais il appelle bind, donc selon ta définition A' est un serveur (pourtant il est pratiquement équivalent à A).

Soit le programme PA similaire à A' sauf qu'en plus il lit sur s (avec recvfrom, recv, ou read). PA est un "serveur" comme A'.

Cependant, deux programmes PA peuvent communiquer entre eux : par exemple, avec deux ordinateurs ordi1 (adresse IP=ip_1) et ordi2 (adresse IP=ip_2) :

• sur ordi1 lancer PA avec d_ip=ip_2, d_port=2001, loc_port=2000
• sur ordi2 lancer PA avec d_ip=ip_1, d_port=2000, loc_port=2001

alors deux "serveurs" communiquent entre eux!

[Emmanuel Delahaye]

C'est ta définition d'un serveur UDP?

Jusqu'à plus ample informé, oui, car c'est lui qui écoute. Mais je suis ouvert aux remarques.

Et un client UDP doit être défini par opposition à un serveur UDP : un client UDP n'est pas un serveur, il communique avec un serveur UDP?

Oui.

A est un "client".

Pour envoyer un paquet UDP à d_ip:d_port depuis un port spécifique, loc_port (programme A') :

• créer une socket UDP s
• initialiser une adresse dest à d_ip:d_port
• initialiser une adresse loc à 0.0.0.0:loc_port
• lier s à loc avec bind (ce qui met la socket en écoute, mais ce n'est pas le but)
• utiliser sendto sur la socket s avec l'adresse dest

Ce programme A' est-il un "client"? En tout cas, il communique avec un serveur, mais il appelle bind, donc selon ta définition A' est un serveur (pourtant il est pratiquement équivalent à A).

Cette manip assez tordue me semble peu orthodoxe. Elle fonctionne ?

alors deux "serveurs" communiquent entre eux!

Il est sans doute possible que 2 serveurs UDP puissent communiquer entre eux, je suppose d'ailleurs qu'il en est ainsi dans le coeur du réseau pour mettre à jour les tables de routage, les DNS et autres bricoles, mais tu admettras que 2 clients (UDP ou autres) ne peuvent pas communiquer entre eux directement.

Ou alors j'ai rien compris, ce qui est toujours possible...

[masterix59]

Je suis désolé de ne pas avoir pu répondre avant, cependant j'ai pu voir que vous avez déja discuté de mon problème, le soucis et que je débute vraiment j'ai voulu me lancer dans ce petit défi et j'ai donc commencer par chercher toute les sources possible sur le sujet.
Voilà ce que j'ai pu en comprendre je fais peut être fausse route n'hésiter pas à me corriger :

Je me suis beaucoup inspiré de : http://emmanuel-delahaye.developpez.com/reseaux.htm
j'ai bien peur de ne pas tous comprendre cependant c'est un début...

Dans mon cas il serait interessant d'avoir un serveur sur un des postes client qui attendrais la connection d'un autre client, le client une fois connecté, la partie peut commencer.
Pour se connecter il faudrais que le client qui se connecte, utilise l'adresse IP de l'ordinateur jouant la tache de serveur.

J'ai peur de m'embrouiller un peu...

Une question certainement logique mais bon... voilà j'aimerais savoir si on lance le serveur sur un poste. Est t'il possible de lancer également un client qui permettra de tester le programme.


J'ai l'impression que personne ne va comprendre ce que je dis tellement ce n'est pas claire dans ma tête :/

Merci d'avance pour vos réponses

[Emmanuel Delahaye]

Dans mon cas il serait interessant d'avoir un serveur sur un des postes client qui attendrais la connection d'un autre client, le client une fois connecté, la partie peut commencer.
Pour se connecter il faudrais que le client qui se connecte, utilise l'adresse IP de l'ordinateur jouant la tache de serveur.

Moui...

Une question certainement logique mais bon... voilà j'aimerais savoir si on lance le serveur sur un poste. Est t'il possible de lancer également un client qui permettra de tester le programme.

Oui, soit avec l'adresse "boucle" (127.0.0.1), soit avec l'adresse locale de la machine (10.0.x.x, 192.168.x.x etc.)