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