Réseaux et Protocoles - Université de Strasbourg
Transcription
Réseaux et Protocoles - Université de Strasbourg
Université de Strasbourg UFR Mathématique et Informatique Licence 3 Informatique Année 2010/2011 Réseaux et Protocoles Projet : Programmation d’un jeu de poker en réseau 1 Introduction Le poker est un jeu de cartes et d’argent très populaire. La variante la plus répandue est le texas hold’em. Dans le cadre du contrôle continu de l’UE Réseaux et Protocoles, nous vous proposons de développer en langage C (ou C++) un jeu de poker en ligne. La variante du poker à implémenter sera donc le texas hold’em. La mise en réseau utilisera l’API socket vu en TD et TP. Le projet est à réaliser en binôme. Vous trouverez dans les sections suivantes les règles du jeu à respecter, les fonctionnalités attendues de votre programme ainsi que les modalités de rendu. 2 Règles du jeu Les règles exposées ci-dessous sont fortement inspirées des pages du site wikipedia sur le texas hold’em : http://fr.wikipedia.org/wiki/Texas_hold%27em). Le Texas hold’em se joue de 2 à 10 joueurs avec un jeu de 52 cartes. Le but du jeu consiste à remporter tous les jetons des adversaires, soit avec une meilleure main que ces derniers, soit en leur faisant abandonner leurs cartes. Lorsqu’un joueur n’a plus de jetons, il a perdu et doit quitter la partie. Les règles de base sont les mêmes que celle du poker classique. 2.1 Valeurs des cartes et mains La couleur d’une carte ne désigne pas rouge ou noir mais pique, trèfle, carreau ou coeur. Toutes les couleurs ont la même valeur. Le rang d’une carte désigne son niveau hiérarchique. Le rang des cartes au poker est le suivant (du plus faible au plus fort) : 2, 3, 4, 5, 6, 7, 8, 9, 10, Valet, Dame, Roi, As. La hiérarchie des différentes mains est la même que pour le poker classique (du plus faible au plus fort) : – La carte haute : le joueur ne dispose d’aucune combinaison connue et par conséquent on regarde la carte de sa main qui a le rang le plus haut ; – La paire : deux cartes identiques (e.g. deux 5) ; – La double paire : deux fois deux cartes identiques (e.g. deux valets et deux 3) ; – le brelan : trois cartes identiques (e.g. trois rois) ; – la suite : cinq cartes qui se suivent dans n’importe quelle couleur (e.g. 4, 5, 6, 7, 8) ; – la couleur : cinq cartes de même couleur (e.g. 5 cartes en coeur) ; – le full : trois cartes identiques plus deux autres cartes identiques (e.g. trois valets et deux 10) ; – le carré : quatre cartes identiques (e.g. quatre dames) ; – La quinte flush : cinq cartes de la même couleur qui se suivent (e.g. 9, 10, valet, dame et roi en pique) ; Lorsqu’il y a égalité sur une combinaison (e.g. deux joueurs ont une double paire aux rois), on regarde les autres cartes de leurs mains. Dans le cas d’une double paire (ou de toutes autres combinaisons multiples), on regarde la paire suivante. Toujours en cas d’égalité, on regarde enfin le rang de la dernière carte de chaque main. En cas d’égalité parfaite, on partage le pot. 1 2.2 Déroulement d’un tour Au début d’une partie, chaque joueur dispose d’une réserve de jetons qu’il va pouvoir miser au cours des différents tours de jeu. Lorsqu’un joueur se retrouve sans jeton, il a perdu et doit quitter la partie. – Au cours d’un tour, trois joueurs ont chacun un rôle particulier : the button, small blind et big blind. Le joueur tenant le rôle the button distribuera les cartes. Le premier joueur à sa gauche sera small blind et le joueur suivant sera big blind. Si la partie ne comporte que deux joueurs, l’un des joueurs aura simultanément le rôle the button et small blind. – Avant la distribution des cartes, les joueurs small blind et big blind doivent s’acquitter des blinds (cf. paragraphe sur les enchères). – La distribution des cartes se fait en deux tours (1 carte à chaque joueur par tour) dans le sens des aiguilles d’une montre en partant du small blind. Les cartes sont distribuées faces cachées afin que les autres joueurs ne puissent pas en prendre connaissance. – Lorsque tous les joueurs ont pris connaissance de leurs cartes, on démarre un premier tour d’enchères (cf. paragraphe sur les enchères) qui débute par le joueur à la gauche du big blind, appelé under the gun et continue dans le sens des aiguilles d’une montre. Ainsi, le small blind et le big blind miseront en dernier. – Après le premier tour de mise, le donneur défausse (face cachée) la première carte du tas et étale le flop. Ce dernier est composé de trois cartes posées faces visibles. Le flop est commun à tous les joueurs, i.e. que les cartes qui le composent sont disponibles pour réaliser des mains. – S’ensuit un nouveau tour d’enchères à partir du small blind. Il en sera de même pour toutes les autres mises de ce tour. – Le donneur défausse à nouveau une carte du tas et étale le turn. Il s’agit d’une carte, face visible, venant agrémenter le flop. – Nouveau tour d’enchères. – Le donneur supprime une dernière carte du tas et étale the river. Il s’agit d’une dernière carte, face visible, venant compléter le flop et le turn. – Dernier tour d’enchères. – Si au moins deux joueurs sont encore en jeu, on procède à l’abattage : chaque joueur encore en jeu montre sa main. Le joueur ayant la main la plus forte remporte le pot. En cas d’égalité parfaite, le pot est partagé équitablement. – A la fin du tour les rôles changent : le joueur small blind devient the button et ainsi de suite. 2.3 Enchères Avant la distribution des cartes, les joueurs small blind et big blind doivent s’acquitter des blinds. Il s’agit de mises fixées au début d’une partie. La big blind est égale à deux fois la small blind. La big blind correspond à la valeur minimum d’une mise (fixé au début d’une partie). Les deux joueurs déposant leurs blind ont la possibilité de faire monter les enchères une fois que les autres joueurs sont rentrés dans la partie. Lors d’une enchère, chaque joueur à le choix entre quatre actions : – suivre (to call) : permet à un joueur de rester dans la partie en ajoutant au pot le nombre de jetons correspondant à la mise en cours. Si la mise en cours est plus importante que le nombre total de jetons d’un joueur, ce dernier peut tout de même suivre en jouant tout son tapis (tout ses jetons d’un coup). – relancer (to raise) : permet à un un joueur de miser plus que la plus importante mise en cours. Il faut d’abord compléter la mise en cours (suivre), puis relancer de jetons supplémentaires. – se coucher (to fold) : permet un joueur de se retirer du tour. Les jetons qu’il avait déjà engagé dans le pot sont perdus. – parler (to check) : permet à un joueur de ne pas miser ni se coucher tout en restant en jeu. Néanmoins cette possibilité n’est applicable qu’à la condition que personne n’ait relancé avant lui dans le tour. 2 3 Fonctionnalités attendues Le projet se déclinera en deux étapes. Avant d’entamer la version améliorée (avec support d’IPv6), la version de base devra être fonctionnelle. 3.1 Version initiale Le projet devra s’articuler autour d’une architecture centralisée client / serveur. Il faudra donc écrire un programme client_POKER et un programme serveur_POKER. Le serveur fera office de croupier : il distribuera les cartes, collectera les jetons en maintenant les comptes, désignera les gagnants d’un tour, etc. Avant de débuter une partie, les joueurs devront patienter dans un lobby qui disposera d’un chat entre tous les utilisateurs connectés. A partir de ce lobby, le joueur principal (le premier connecté) pourra à tout moment débuter la partie avec les joueurs présents. Lors du déroulement d’une partie, le serveur n’acceptera plus de nouvelles connexions. Par conséquent, il ne peut y avoir qu’une partie par serveur. En revanche, le serveur devra être capable de gérer la déconnexion de joueurs en cours de partie. Le protocole de transport utilisé sera TCP. Le serveur et les clients communiqueront via IPv4. Concernant les données véhiculées entre le serveur et les clients, c’est à vous de choisir le type de données et leur format. Gardez à l’esprit qu’il faut que le tout soit sécurisé, on ne souhaite pas qu’un joueur malintentionné puisse tricher. 3.2 Support d’IPv6 Lorsque la version initiale sera fonctionnelle, vous pourrez vous atteler au développement d’une version améliorée qui apportera le support d’IPv6 dans les communications. Du côté serveur, ce dernier devra accepter des connexions en IPv6 et en IPv4. Votre programme client devra lui privilégier l’utilisation d’IPv6. Si une connexion IPv6 est impossible depuis un hôte, alors le programme client devra se rabattre sur une connexion IPv4. 4 Rendu Ce projet est à réaliser en binôme. Vous devrez rendre à la fois le code source en langage C (ou C++) ainsi qu’un rapport détaillant l’implémentation et les choix techniques (entre 5 et 10 pages). Dans un premier temps, vous devrez rendre un pré-rapport qui découpe le projet en “lots”. Chaque lot consiste en une partie spécifique du programme final. Par exemple, le premier lot pourrait être la mise en place d’une connexion TCP en IPv4 entre deux hôtes. Le deuxième lot pourrait être l’implémentation du chat multi-utilisateurs et ainsi de suite. Chaque lot aura un responsable et une échéance. De cette manière, avant de débuter la programmation à proprement parler, le projet sera correctement planifié. Ce premier document sera à rendre pour le 11 mars au plus tard. Une fois ce premier document re¸u, nous vous créerons un accès SVN. 4.1 Code Votre code devra être hébergé sur un serveur subversion (SVN). Il s’agit d’un système de gestion de versions généralement utilisé dans les projets informatiques. A chaque modification de votre code, vous devrez mettre à jour vos modifications sur votre dépôt SVN (e.g. ne pas faire une unique mise à jour de votre dépôt à la fin de votre projet). Pour information, nous serons attentifs à la fréquence des mises à jours de votre dépôt. Les paramètres du serveur vous seront communiqués ultérieurement lorsque les groupes seront constitués et vos pré-rapport reçus. Un dépôt SVN est généralement organisé selon trois répertoires : – trunk : contient la version principale en cours de développement du projet. C’est dans ce répertoire que vous travaillerez principalement. 3 – branch : contient généralement des copies du projet qui ont dérivées depuis un certain point par rapport à la version en cours de développement (celle contenue dans trunk). Ces copies ont pu être initiées pour développer de nouvelles fonctionnalités ou des révisions majeures du code tout en préservant l’intégrité du code principal (qui se trouve dans trunk). Si les changements fonctionnent, ces versions divergentes peuvent être intégrées par la suite à la branche principale du projet. – tag : contient des images du code principal (trunk) ou d’une branche (branch) à un certain point dans le temps. Une image est figée dans le temps et n’est en théorie plus soumise à modification. Les deux principales raisons de faire des images d’un code sont soit pour une publication du code et donc du logiciel (release), soit pour figer une version stable du programme de manière à pouvoir effectuer des révisions majeures dans le dépôt principal sans nuire aux utilisateurs désireux d’avoir une version stable. La politique de création de branches ou tags est entièrement soumise à votre expertise. La version finale de votre projet (celle que votre chargé de TP viendra récupérer) devra faire office d’un tag final-version. De plus, devrez porter une attention toute particulière aux points suivants : – votre code devra avoir été rédigé selon les règles de bonne pratique en vigueur (http://clarinet.u-strasbg. fr/~montavont/web/ens/howto-coding.pdf); – votre code devra ne contenir aucune fuite de mémoire ; – vous devrez fournir un Makefile qui permettra de lancer la compilation automatiquement. En outre, il faudra utiliser les options de compilations suivantes : – g, W, Wall, Wmissing-declarations, Wmissing-prototypes, Wredundant-decls, Wshadow, Wbad-functioncast, Wcast-qual, Werror Votre code inclura également les fichiers INSTALL et README habituels ; – votre code devra être structuré (découpage en bibliothèques, etc.) ; – chaque fichier, fonction, argument et retour devra être commenté selon la norme utilisée par doxygen. Le code devra absolument 1 pouvoir fonctionner en effectuant les tâches suivantes : 1. 2. 3. 4. 5. 6. 7. svn checkout cd nom-du-binome/tag/final-version/server/ make ./poker-server port_number cd ../client/ make ./poker-client addr_serv port_number 4.2 Rapport Le rapport de projet devra vérifier les règles suivantes : 1. 2. 3. 4. 5. il détaillera succinctement le fonctionnement du protocole mis en place entre le serveur et les clients ; il décrira clairement la démarche adoptée et les difficultés techniques rencontrées ; il détaillera les choix en termes protocolaires et notamment pour la gestion de la double pile IPv4 et IPv6 ; vous décrirez les principaux tests que vous avez effectués pour vérifier le bon comportement de votre code ; vous attacherez une importance particulière à la concision de vos explications. Toute explication superflue doit notamment être supprimée (i.e. small is beautiful) ; 6. vous préciserez la répartition quantitative des rôles (fonctions implémentées, etc). Toute forme de plagiat 2 sera équivalent à la non-remise du rapport. Une version électronique du rapport devra se trouver dans votre dépot SVN avec le code source. 1. tout échec à ce test impliquera un code considéré comme non fonctionnel 2. http://fr.wikipedia.org/wiki/Plagiat 4