Page suivante
Page précédente
Table des matières
Nous décrivons ici le protocole utilisé pour les échanges d'informations
entre le serveur et ses différents clients.
Nous avons choisi de faire communiquer le serveur avec les clients par
l'intermédiaire d'un protocole de type "clear text", c'est à dire
constitué de messages facilement compréhensibles sous la forme de chaînes
de caractères lisibles (comme le font de nombreux autres protocoles SMTP,
FTP, IRC, etc.).
Le fait de faire communiquer les
clients/serveurs par l'intermédiaire de messages lisibles par un être humain
permet de comprendre très facilement ce qui se passe, de tester et d'envoyer
des messages entrés à la main, et de rester compatible au niveau des blocs de
données quel que soit le type de machine. Le seul inconvénient est qu'il y
a plus d'informations à envoyer par rapport à des envois en binaire. Mais
pour ce projet, la vitesse et la quantité d'informations à transférer était
négligeable.
Conventions d'ecriture
- le_mot
signifie que l'argument n'est en fait qu'un seul mot et ne doit
donc contenir aucun espace
- la chaine
signifie que l'argument est une chaine pouvant contenir des espaces
- {informations}
signifie que l'argument est un ensemble d'informations structurées
sous forme de listes imbriquées
Description d'un message
Un message est constitué de deux parties:
- La partie clef
- La partie options dependant de la clef de message. Sur certains
messages cette partie est inexistante
Un message est une chaîne sur une seule ligne délimitée par un retour
chariot. Par ailleurs, chacun des messages échangés ne
constitue qu'une seule ligne. Le délimiteur de message est donc le retour
chariot qui permet de différencier les lignes de messages échangées.
Différents types d'échanges utilisés
Le protocole est basé sur 2 types d'échanges de messages :
- l'échange "émission d'un message"
- l'échange "émission d'un message/réponse à ce message"
Ces différents échanges ont toujours lieu entre un des clients et le
serveur. L'échange d'information entre les différents clients est effectué
par le serveur lui-même, selon la forme :
"émission d'un message/diffusion d'un autre message aux autres
clients/réponse à cet autre message/réponse au message initial"
L'acceptation et le refus
Dans le cas du deuxième type d'échange, la réponse attendue en retour est
souvent une acceptation ou un refus de la donnée envoyée précédemment. Ceci
est effectué par un message en retour :
- acceptation :
OK chaîne de caractères ou données renvoyées
où la chaîne est un message informatif qui n'est
normalement pas utilisé par la partie réceptrice
qui se satisfait uniquement du OK.
- refus :
BAD chaîne de caractères
où la chaîne de caractères sert à passer à la
partie réceptrice la raison de ce refus, et pourra
donc être utilisée par la partie réceptrice.
Voyons maintenant les détails du protocole en analysant les différentes
phases du jeu.
Début de partie
- MSG le message
- Sens : serveur vers client.
- Réponse : aucune
- Fonction : permet, par exemple, au
serveur de passer au client le "message du jour"
juste après la connexion, ou encore des messages
informatifs en cours de partie.
\begin{figure}[!hbtp]
\begin{center}
\epsffile{figures/msg.eps}
\caption {\it Message echange lors de l'envoi d'un message informatif par le serveur}
\end{center}
\end{figure}
S'identifier auprès du serveur
- NICK le_surnom
- Sens : client vers serveur.
- Réponse :
- OK
si le surnom est accepté par le
serveur
- BAD le message
si le surnom est refusé
par le serveur (par exemple si il est déjà utilisé
par un autre client)
- Fonction : permet au client de communiquer au serveur
le surnom utilisé par le joueur.
- Effet : Le serveur enverra ensuite un message GAMES
(voir ci-dessous) afin de fournir au client la liste des
informations sur les parties en cours.
- GAMES {informations sur les parties et les joueurs}
- Sens : serveur vers client
- Réponse :aucune
- Fonction : permet au serveur de fournir au client
les informations sur l'ensemble des parties et des
joueurs.
Les informations passées au client sont :
- l'ID de la partie : celui-ci est un entier fixé par le serveur
à la création de la partie
- le nom de la partie : celui-ci est fourni par le client à la
création de la partie et est un seul mot
- le type de jeu de la partie (morpion ou puissance 4)
- la largeur de la grille de jeu
- la hauteur de la grille de jeu
- la liste des informations sur les différents joueurs sur la partie:
- l'ID du joueur : celui-ci est un entier fixé par le serveur
après la saisie du surnom
- le nom (ou surnom) du joueur comme saisi par ce dernier
au debut du jeu
- la nom de la machine depuis laquelle est connecté le joueur
Les informations sont passées sous la forme de liste imbriquées :
{
{id_partie_1 nom_partie_1 type_partie_1 largeur hauteur {
{id_joueur_1 nom_joueur_1 machine_1}
{id_joueur_2 nom_joueur_2 machine_2}
}}
{id_partie_2 nom_partie_2 type_partie_2 largeur hauteur {
{id_joueur_3 nom_joueur_3 machine_3}
{id_joueur_4 nom_joueur_4 machine_4}
{id_joueur_5 nom_joueur_5 machine_5}
}}
}
Attention : Nous représentons ici les informations sur plusieurs
lignes pour des raisons de lisibilité, mais dans la pratique l'ensemble du
message est sur une seule ligne.
\begin{figure}[!hbtp]
\begin{center}
\epsffile{figures/nick.eps}
\caption{\it Messages echanges lors de l'identification du joueur auprès du serveur}
\end{center}
\end{figure}
Créer une nouvelle partie
- NEW nom_partie largeur hauteur type_jeu
- Sens : client vers serveur.
- Réponse :
- OK id_partie
si la création de la partie est
acceptée par le serveur
- BAD le message
si la création est refusée
par le serveur (par exemple si le nom est déjà utilisé
pour une autre partie ou si la taille de la grille
est hors limites)
- Fonction : permet au client de créer une nouvelle partie
- Effet : Ceci provoque l'envoi à tous les clients
d'un message GAMES (voir ci-dessus), puis au joueur
d'un message PLAY (voir ci-dessous) afin de lui indiquer
que c'est son tour de jouer.
- PLAY id_partie id_joueur
- Sens : serveur vers client.
- Réponse : Aucune
- Fonction : permet au serveur de signifier au client
à qui est le tour de jouer sur la partie
\begin{figure}[!hbtp]
\begin{center}
\epsffile{figures/new.eps}
\caption{\it Messages echangees lors de la creation d'une nouvelle partie}
\end{center}
\end{figure}
Integrer une partie exsitante
- JOIN id_partie
- Sens : client vers serveur.
- Réponse :
- OK
si le client est accepté par les
autres clients sur la partie spécifiée
- BAD le message
si le client est refusé
par au moins un des autres clients
- Fonction : permet au client de joindre une partie
existante
- Effet : Si le joueur est accepté dans la partie, ceci
provoque l'envoi à tous les autres clients présents sur
la partie spécifiée d'un message GAMES, et ensuite au
joueur un message GRID et un message PLAY.
Le joueur venant d'intégerer la partie jouera en dernier, c'est à dire juste
avant le joueur dont c'est le tour au moment du JOIN.
- JOIN id_partie nom_joueur
- Sens : serveur vers client
- Réponse :
- YES id_partie nom_joueur
si l'accès à cette
partie est accepté par le client
- NO id_partie nom_joueur
si l'accès est refusé
- GRID id_partie {les informations sur les coups déjà joues}
les informations sont passées sous la forme de liste imbriquées :
{
{id_joueur_1 {x1 y2} {x2 y2} ... {xn yn}}
{id_joueur_2 {x1 y2} {x2 y2} ... {xn yn}}
}
Attention : Nous représentons ici les informations sur plusieurs
lignes pour des raisons de lisibilité, mais dans la pratique l'ensemble du
message est sur une seule ligne.
- Sens : serveur vers client.
- Réponse : Aucune
- Fonction : permet au serveur d'envoyer au client les
coups déjà joués sur une grille
\begin{figure}[!hbtp]
\begin{center}
\epsffile{figures/join.eps}
\caption{\it Messages echanges lors d'une demande d'integration de partie}
\end{center}
\end{figure}
Jouer
- HIT id_partie x y
- Sens : client vers serveur.
- Réponse :
- HIT id_partie x y id_joueur
si le coup est
accepté par le serveur. Ce message est envoye
a tous les joueurs de la partie.
- BAD le message
si le coup est refusé
par le serveur
- Fonction : permet au client d'envoyer au serveur le
coup qu'il vient de jouer
- Effet :
- Si personne ne gagne et que la grille n'est pas pleine :
ceci provoque l'envoi à tous les autres
clients présents sur la partie spécifiée
d'un message PLAY indiquant à qui est
maintenant le tour de jouer.
- Si un joueur gagne :
ceci provoque l'envoi à tous les autres
clients présents sur la partie spécifiée
d'un message WIN indiquant le joueur ayant
gagné la partie, puis d'un message GAMES ne
contenant plus cette partie puisqu'elle est desormais terminée.
- Si la grille est pleine et que personne ne gagne :
ceci provoque l'envoi à tous les autres
clients présents sur la partie spécifiée
d'un message END indiquant le match nul, puis
d'un message GAMES ne
contenant plus cette partie puisqu'elle est désormais terminée.
\begin{figure}[!hbtp]
\begin{center}
\epsffile{figures/hit_ok.eps}
\caption{\it Messages echanges lors d'un coup valide}
\end{center}
\end{figure}
\begin{figure}[!hbtp]
\begin{center}
\epsffile{figures/hit_bad.eps}
\caption{\it Messages echanges lors d'un coup refuse}
\end{center}
\end{figure}
- WIN id_partie id_joueur
- Sens : client vers serveur.
- Réponse : serveur vers client
- Fonction : est envoyé à tous les clients de la partie
quand un joueur gagne
\begin{figure}[!hbtp]
\begin{center}
\epsffile{figures/hit_win.eps}
\caption{\it Messages echanges lors d'une victoire par un joueur}
\end{center}
\end{figure}
- END id_partie
- Sens : serveur vers client.
- Réponse : serveur vers client
- Fonction : est envoyé à tous les client de la partie
quand la grille est pleine et que personne n'a gagné
\begin{figure}[!hbtp]
\begin{center}
\epsffile{figures/hit_end.eps}
\caption{\it Messages echanges lors d'un match nul}
\end{center}
\end{figure}
Quitter la partie en cours
- QUIT id_partie
- Sens : client vers serveur.
- Réponse :aucune
- Fonction : permet au client de signifier au serveur
qu'il quitte la partie spécifiée.
- Effet : Ceci provoque l'envoi à tous les autres
clients d'un message QUIT (dans le sens serveur
vers clients, voir ci-dessous).
- QUIT id_partie id_joueur
- Sens : serveur vers client
- Réponse :aucune
- Fonction : permet au serveur de signifier aux autres
clients que le joueur spécifié quitte la partie
spécifiée.
- Effet : Ceci provoque l'envoi à tous les clients
restant d'un message GRID (afin qu'ils
puissent réafficher une grille ou les coups du joueur
ayant quitté la partie seront représentés par une
autre icone), puis d'un message PLAY indiquant
à qui est le tour de jouer (au cas ou on attendait
avant le QUIT le coup du joueur qui a decidé
de quitter la partie).
\begin{figure}[!hbtp]
\begin{center}
\epsffile{figures/quit.eps}
\caption{\it Messages echanges lors du depart d'un joueur d'une partie}
\end{center}
\end{figure}
Page suivante
Page précédente
Table des matières