Re: [Maitretarot-devel-fr] Protocole, encore...

[Jeremie Koenig]

On Thu, Jan 16, 2003 at 06:40:28PM +0100, Yves Mettier wrote:
> 
> > Au cas ou ca interesserait quelqu'un, j'ai foutu mes specs de protocole
> > sous une forme lisible et je les ait foutues en ligne:
> >
> >     http://sprite.fr.eu.org/belote/protocol.txt
> >
> > J'aimerais beaucoup avoir des commentaires etant donne votre
> > experience avec maitretarot...

> Je l'ai lu un peu vite.
> Tu as un :prefix facultatif interessant si on veut faire du routage. Par
> contre, quel interet? Admettons. On peut aussi le mettre dans maitretarot
> etant donne qu'il est facultatif. On ne s'en servira pas tant qu'on n'y
> verra pas l'utilite.

Exemple quand ou joue a un jeu, du point de vue du client :
<- 421 :You lead the trick, please play a card
-> card hk       (ou h14 ou h140 ou n'importe quelle forme que ca prend
                  quand on l'encode...)
<- :joe card hk
<- :jack card hq
<- :foo card t12
<- :bar msg :tu crois peut etre que tu vas t'en tirer comme ca ! 
<- :bar card t15
<- 007 bar :wins the trick
etc...

L'interet est de savoir qui fait quoi, envoie un message, joue une
carte, etc... Ca vient du fait que j'ai une approche asynchrone, a mon
avis plus generale. L'approche qu'a la protocole IRC me plait beaucoup,
c'est vrai. Ca vient peut-etre du fait que je me suis deja un peu amuse
a coder des trucs genre bot IRC, etc... Au debut j'avais envisage de
pondre un truc presque compatible avec IRC, et quelques commandes
etendues, histoire de pouvoir jouer avec bitchx et des /quote
barbares... c'est pour dire ;)

Certe on n'est pas en train de concevoir un systeme de chat a
l'echelle mondiale ;) Mais AMHA l'approche fondamentale, dont le truc
central est en fait le message, qui est propage, reste tres _tres_
interessante.

Petite remarque : dans l'exemple, moi c'est joe. Le serveur me renvoie
le message que je lui ait envoye. Ca simplifie pas mal de truc, et c'est
plus simple qu'un ack tout con. Quand on envoie une carte, le serveur
peut faire ca (renvoyer le message) ou envoyer un code d'erreur.

Le client a juste besoin de savoir que quand je clique sur un carte
(admettons que c'est un client graphique), il doit envoyer un message
"card" au serveur. Quand il recoit un message card, il affiche la carte
pres du joueur donne comme prefixe, quand il recoit une erreur il
l'affiche. Il n'a pas besoin de suivre le jeu ! Pas besoin de connaitre
les regle, l'ordre dans lequel ca tourne, etc...

En plus, je peux utiliser une commande du client a la "/quote" pour
jouer une carte, il n'en sera pas deroute pour autant, et il n'a pas
besoin de comprendre ce que je fais pour suivre.

> Il te manque une notion de type de message, si c'est un message
> informatif, une demande ou une reponse a une demande. Cette notion peut
> tres bien etre implicite suivant ce que nous appelons la clef et toi la
> commande. Cependant, il est bien plus facile d'expliciter cette notion.
> C'est cette notion que nous appelons commande dans le protocole de
> maitretarot (et qu'on devrait peut-etre renommer type?)

Si un client/serveur connait le protocole (et il vaut mieux ;), il sait
de quoi il s'agit.. S'il ne le connait pas, ou mal, savoir si on lui
demande quelque chose, si on l'informe ou si on lui repond ne l'aide pas
vraiement..

En plus, la distinction demande/reponse/info n'est pas si evidente.
Quelqu'un fait quelque chose ? Je recoit un message, qui traduit
l'action, avec un prefixe, qui me dit qui fait l'action en question. Je
veux faire quelque chose ? J'envoie un message (et si le mec ou l'IA qui
joue connait les regles, pas besoin que le serveur me le demande). Je
recoit quelque chose du serveur (c'est a dire sans prefixe), c'est qu'il
m'informe de l'etat du truc. Et pas besoin de savoir si c'est parcequ'il
a envie ou si c'est parceque je lui ait demande (je me trompe ?) En tout
cas une tonne de clients IRC (je sais, je fais un obsession, et c'est
pas pareil ;) marchent tres bien sans depuis 10 ans ou quelque chose
comme ca...

> Il y a des aspects d'IRC que tu as pris et adaptes mais qui en pratique
> sont peu interessants. Un exemple: ta notion de canaux. je ne vois pas son
> utilite.

C'est peut-etre le nom qui ne colle pas... Un canal, c'est une partie si
tu prefere. Avoir differents canaux permet a des personnes differentes de
jouer en meme temps sur un meme serveur, en utilisant des canaux
differents.

Remarques qu'au debut, il n'y aurait pas besoin d'implementer tout ca,
on peut considerer que le serveur ne fait jouer qu'une partie a la fois
et oublier le commandes qui concernent les canaux.

> Derniere chose sur tes arguments de protocole texte/binaire. Dans le cas
> qui nous interesse, le protocole binaire et le protocole texte prennent
> autant de bande passante. Il n'y a aucune difference.

Disons pas grand chose.. 0x1234 prends 2 octet, alors que "showcards" en
prends plus. La meme chose s'applique pour l'encodage des cartes, par
exemple.

> De plus, si tu
> penses aux little/big endian en disant que le protocole binaire est plus
> difficile a implementer que le protocole texte, eventuellement, oui.

Off, j'ai dit ca ?.. Je crois pas que le protocole binaire soit
vraiement plus dur a implementer (c'est pas une paire de ntohl/htonl qui
va nous faire peur!). Ceci dit, c'est moins embetant a debugger (je me
suis deja amuse a faire des hexdump de partout avec des specs de
protocoles sur la console d'a cote, c'est pas de la tarte !)

> Ceci dit, rien que pour des questions de deboguage, le protocole texte est
> a preferer!

Ah, pardon, j'avais pas vu la remarque ;)

> Pour le reste, je crois que les seules differences tiennent du vocabulaire
> employe pour les mots-clefs et au codage des donnees.

Ptet ben qu'oui, ptet ben qu'non ;) 

> Yves

Oups, vi affiche 130 lignes. Desole pour le pave ;)

-- 
Jeremie Koenig <address@hidden>