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

[Yves Mettier]

> 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.

Pour un systeme completement distribue, un protocole base sur irc est tres
interessant. Cependant, la, nous avons un systeme centralise, avec un
serveur qui gere la partie et verifie que les regles du jeu sont
respectees.
DU coup, le protocole irc ne presente plus grand interet (meme s'il reste
peut-etre quand meme des choses a piquer)

>
> 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.

Pour maitretarot, nous partons quand meme du principe que les clients
peuvent faire n'importe quoi, meme tricher. Le serveur est la pour
garantir que les regles sont respectees.
Par consequent, l'aspect propagation du message perd beaucoup de son
importance par rapport a ton systeme qui vise seulement a propager le
message, chacun faisant ce qu'il veut du message.

Ce qui est genant avec un systeme comme le tien, c'est qu'il suffit
d'avoir un client qui fait n'importe quoi, ne respecte pas la regle, ou
met un peu n'importe quoi dans les messages (en respectant la syntaxe), et
le systeme est par terre. On est rapidement amene a ameliorer un tel
systeme en mettant plus de controles sur le serveur, et on aboutit au
systeme que nous voulons pour maitretarot.

Et tu remarqueras que IRC, c'est tout le contraire: tout le monde peut
ecrire n'importe quoi. les seules interdictions sont de piquer le nick a
quelqu'un qui est deja en ligne, et le serveur irc fait ce boulot de
verification. Le serveur irc ne fait ensuite que du boulot de verification
de syntaxe (plus de la configuration quand on s'adresse a nickserv ou
chanserv par exemple).

Tant qu'on y est, tu peux venir nous voir sur #maitretarot sur
irc.freenode.net :)

>
>> 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..

Bah si. L'idee est que si un client connait mal le protocole (parce que
des ajouts ont ete fait et que le client ne sait pas les prendre en compte
- ancienne version), il peut toujours determiner s'il doit juste prendre
en compte le message du serveur (le passer a la trappe s'il ne sait pas
l'interpreter), ou si on lui demande une reponse. Et dans le cas ou on lui
demande une reponse et qu'il ne sait pas repondre, il saura toujours dire
qu'il ne sait pas, reponse qui fait partie du protocole.
Ensuite, libre au serveur de garder le client si le message est peu
important, ou de virer le client si le message est necessaire au bon
deroulement du jeu.

Exemple: si le serveur annonce qu'un joueur a la poignee (au tarot) et
qu'un client ne comprend pas, cela ne nuit pas au jeu (simplement, le
joueur ne saura pas qu'il y a une poignee). Si le serveur demande s'il y a
des annonces, le client pourra toujours dire qu'il ne sait pas, et tant
pis si le joueur avait une misere d'atouts a annoncer.
Avec un protocole qui ne prend pas en compte la notion de type de
messages, si un message est inconnu, le client ne peut pas savoir s'il
doit repondre ou juste prendre en compte le message.

>
> 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...

J'illustre mon propos. Si on met eorhgeorg dans le protocole, et que le
serveur te dit "eorhgeorg", tu fais quoi? Tu lui reponds ou non? Et si
oui, tu lui reponds quoi?
Avec le type de message, si le serveur te dit "info eorhgeorg", t'as pas a
lui repondre. S'il te dit "ask eorhgeorg", tu lui reponds "say dunno" (I
don't know :) Et la au moins le serveur il sait que tu connais pas ce
point du protocole, et si c'est indispensable au jeu, il te le fait
comprendre.

>
>> 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.

Oui, c'est un peu comme ca qu'on fait.
Mais peut-etre faudrait-il prendre cela en compte?
On rajoute un champ? Philippe?


>
>> 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.

Tant qu'on depasse pas les 1100 octets, c'est le meme cout, 2 ou 9 octets.

>
>> 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 !)

Bon, alors j'ai depasse ta pensee. n'empeche que dans ton protocole, tu
mets quand meme que le binaire est un peu moins facile a implementer que
le texte.

[...]

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     -