Re: [Maitretarot-devel-fr] protocole

[Yves Mettier]

> "Yves Mettier" <address@hidden> writes:
>
>> Coucou!
>>
>> Nouvelle version du protocole, apres discussion avec Philippe
>> (hocwp).
>>
>> Principe: le serveur met a disposition des clients le contenu de
>> certaines variables. Les clients ont donc pour principe de demander
>> au serveur ou on en est, en fonction des besoins.
>> Entre autres, le serveur met une variable indiquant l'etat du jeu
>> (par exemple, le contenu de cette variable contient une valeur
>> indiquant que c'est au joueur 3 de jouer).
>>
>> De plus, le serveur doit pouvoir demander des choses au client
>> (exemple: "tu te bouge le cul et tu joue ta cartes, steup?").
>>
>> Le principe du jeu, ensuite, sera que chaque client est amorphe (a
>> moins qu'il ne veuille faire des choses par lui-meme). Et le serveur
>> envoie des requetes "balance-moi tel truc steup" au client qui doit
>> renvoyer ce qu'il faut.
>>
>> Pour la forme, le protocole de Jerome me plait bien. Il a juste un
>> inconvenient: c'est un systeme a base d'ordre et de valeur. Il nous
>> faut, pour avoir une bonne resistance aux pannes, un systeme a base
>> d'ordre, de clef et de valeurs.
>> Exemple:
>> client->serveur: SET carte_jouee 11
>> Ou alors:
>> serveur->client: INFO joueur1 11   (pour dire que le joueur 1 a joue
>> le 11 de carreau)
>>
>> Il nous faut donc inventer tout un vocabulaire pour cela. Mais ce
>> qu'il faut retenir, c'est que tout message envoye sur le reseau sera
>> compose d'un ordre, d'une clef et d'une valeur (meme si la valeur
>> doit etre ignoree :)
>>
>
> ok, donc si j'ai bien compris, pour le debut de partie, ça peut
> donner un truc du genre :

On parle du debut de la *partie*, parce qu'il y a des choses qui
precedent pour le debut de la *connexion*.

>
> * le client reçoit ses cartes :
>
> serveur->client: SET carte_en_main 11 22 44 45 ...

oui

>
> * les encheres :
>
> serveur->client: DEMAND(?) enchere
>
> client->serveur: GET enchere_autres_joueurs


Pas clair, ce "DEMAND". "ASK" est meilleur.
Oui, ici, c'est plutot un cas exotique, qui peut arriver et que le
serveur doit savoir gerer.
Normalement, le serveur doit d'abord envoyer l'etat de encheres au
client, puis faire ce ASK. Et dans ce cas, la reponse normale du client
devrait etre un truc comme "SAY mon_enchere passe"

D'ailleurs, je trouve ces mots-clefs sympa, ASK pour le serveur et SAY
pour le client. Ca nous rapproche de la realite. INFO pour le serveur
aussi, cf juste apres

> serveur->client: SET enchere_autres_joueurs b1 b2 b3 b4 b5
> (avec b1,... les encheres des autres joueurs)

Ici, INFO est mieux. Sinon, oui, c'est ca.

>
> client->serveur: SET enchere 2

Non. Justement, ici, on reproduit le pb du protocole version 0.1 (c'est
bien 0.1 la version actuelle?) Si le serveur annonce les encheres des
autres joueurs, il ne demande rien au client. Dans ce cas, le client
doit fermer sa gueu... sa sortie :)

Pour les encheres, il faut s'attendre plutot a ceci:

S->C: INFO encheres b1 ? ? ? ?
S->C: INFO encheres b1 b2 ? ? ?
S->C: ASK enchere
C->S: SAY b3
S->C: INFO encheres b1 b2 b3 b4 ?
S->C: INFO encheres b1 b2 b3 b4 b5

D'ailleurs, je m'apercois qu'il existe un bug dans le serveur (et dans
les clients actuels?): si deux joueurs font une enchere, c'est le
deuxieme (qui a surencheri, forcement) qui fait le jeu. Dans la regle du
jeu, le premier devrait pouvoir surencherir ou passer. ceci n'est pas
implemente dans maitretarot-0.1.1.


>
>
> etc...
>
> et la même chose pour les joueurs qui attendent...

... et la meme chose pour les joueurs qui attendent evidemment.

>
> enfin, il y a moyen de simplifier un peu (exemple le
> serveur envoi les encheres des autres joueurs au moment
> ou il fait la demande des encheres).

Non. C'est possible, mais cela suppose que le client sait decoder quand
il doit faire son enchere en fonction de la valeur d'une clef. Je
prefere que le client ne reponde qu'a certains messages en fonction de
la commande, jamais en fonction ni de la clef ni de la valeur de la
clef.
Typiquement, un joueur devra toujours repondre a une commande ASK et
jamais a une commande INFO.


Question: doit-on implementer une commande ACK, reponse du client au
serveur lorsque le serveur envoie une commande INFO?
Avantage: ca permet au client d'en profiter pour demander autre chose
s'il en a besoin, puisque le client n'a le droit de parole qu'en reponse
a une demande du serveur. Mais est-ce necessaire?
Inconvenient: Ca nous rajoute du trafic reseau quasi inutile. Quasi
inutile ou vraiment inutile? Meme si c'est inutile, vu que l'application
n'est pas specialement gourmande en bande passante, doit-on economiser
ici?


Autre remarque: le chat. A mon avis, alors que tout le reste est
synchrone (le client ne parle que si le serveur a fait une demande), le
chat est asynchrone. On peut le faire passer via une commande CHAT. Cela
devrait un poil compliquer les clients qui veulent gerer cette
fonctionnalite future. Cela devrait beaucoup compliquer le serveur qui
du coup doit ecouter sur ses sockets a tout moment. Je suis assez pour
implementer un support possible de cette fonctionnalite, car si on ne
prevoit pas cette
fonctionnalite a l'avance, il faudra recoder le serveur quasi en entier
si on veut implementer une fonctionnalite asynchrone, quelle qu'elle
soit. Mais est-ce vraiment la peine pour le chat?
Il y a irc, icu et d'autres protocoles pour discuter en meme temps. Un
tel protocole rajoute peut-etre des problemes de securite (quoiqu'a
premiere vue je n'en vois pas). Bref, on verra ca plus tard. Ne nous
fermons pas les portes :)

Yves

-- 
- Homepage - http://ymettier.free.fr - http://www.cmg.com -
- GPG key  - http://ymettier.free.fr/gpg.txt              -
- MyAM     - http://www.freesoftware.fsf.org/myam         -
- GTKtalog - http://www.freesoftware.fsf.org/gtktalog     -