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

[Yves Mettier]

> On Thu, Jan 16, 2003 at 11:07:46PM +0100, Yves Mettier wrote:
>
>> 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)
>
> Si j'avais a reecrire un protocole comme IRC pour un seul serveur, je
> garderais le meme (evidemment avec toutes les commandes en trop en
> moins, mais la structure du protocole resterait la meme, ce que j'ai
> l'intention de faire pour ma belote..)
>
> Qu'est-ce qui n'est plus valable ?

Pas valable? Non, c'est un peu extreme, la. Simplement moins adapte. En
particulier le fait que certains messages necessitent une reponse de la
part du client, ce qui n'existe pas dans irc. Ou alors l'aspect asyncrone
d'irc alors que le principe (je parle du principe pas du protocole) est
synchone.
Donc on peut effectivement utiliser un protocole asynchrone pour une
communication synchrone, mais cela oblige l'implementation de couches au
dessus du protocole pour que tout soit synchrone. Moi, je prefere que le
protocole soit lui-meme synchrone.

>
>> > 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.
>
> En fait, tout ca me semblait evident. Il est certain que le serveur
> validera tous les messages recus du client. Je devrais le specifier
> explicitement dans la doc, pas finie. Si un client envoie un message
> illegal (qu'il s'agisse de triche ou simplement d'une faute de frappe),
> le serveur renvoie une erreur au client au lieu de propager le message.
>
>> 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).
>
> C'est faux. Tous les messages sont valides. Si j'essaye de kicker
> quelqu'un et que je ne suis pas op, ca na va pas. Si je parle trop vite,
> le serveur me jette, etc, etc..

y'a aussi la gestion des droits effectivement, et certains points qui
garantissent que tu floodes pas trop le chan. Bon, c'etait pas ce que je
voulais dire.
Avec irc, tu tapes un texte: tu peux ecrire n'importe quoi, et surtout
n'importe quand. Avec maitretarot, tu peux pas jouer le valet de coeur si
tu l'as pas (verification qui se fait sur le serveur, et on peut dire que
ca ressemble au kick quand t'es pas op), mais surtout, si tu as la dame de
pique, tu peux pas la jouer n'importe quand. Seulement a ton tour (et je
ne parle meme pas du fait que si on joue coeur, la dame de pique a de
grande chances d'etre refusee). On revient en fait sur le caractere
asynchrone de irc alors que celui de maitretrarot est synchrone.



>
> Il n'y a que pour la commande PRIVMSG que le controle n'est pas
> faramineux (et encore...), ce qui peut donner une impression de
> "laxisme", mais on ne peut pas injecter n'importe quel message dans le
> systeme.
>
>> Tant qu'on y est, tu peux venir nous voir sur #maitretarot sur
>> irc.freenode.net :)
>
> Peuh.. il y a que des bots a cette heure ;)

mouarf
!meteo paris
!meteo [prev] paris
!google maitretarot

>
>> > 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.
>
> En fait, je ne vois pas trop dans quel cas le serveur peut avoir quoi
> que ce soit a demander au client. Une carte ? des trucs comme ca ? Quel
> interet ? Le client (si c'est une IA) ou le mec qui est a la souris
> savent jouer..

On parle de protocole.
Et le client peut justement ne pas savoir jouer.

On peut effectivement partir sur un principe ou tout le monde sait jouer,
et tout le monde joue a son tour, comme si on etait autour d'une table, le
serveur ne servant qu'a loguer et a verifier la regle, rien de plus. Dans
ce cas, je pense que c'est d'ailleurs une coincidence parce qu'on n'a pas
du tout pense a cela au contraire, on arrive a un protocole comme celui
actuellement utilise dans maitretarot. Et celui qu'on a actuellement, on
le change principalement parce que la moindre erreur d'interpretation du
protocole entraine un bug (et pas un dysfonctionnement qu'on detecte tout
de suite), et aussi parce que le moindre changement necessite un
changement du serveur et des clients *en meme temps*.
Donc la non, on connait deja ce genre de protocole, et on veut faire autre
chose.

>
>> 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.
>
> Si le serveur annonce qu'un joueur a une poignee, il n'est pas utile
> pour lui d'attendre une reponse. Pour ce qui est des annonces, je ne
> m'attends pas a ce que le serveur demande quoi que ce soit, c'est au
> joueur de demander au client de l'annoncer au serveur (eventuellement
> une fonction automatique du client peut entrer en jeu) avant le premier
> pli, dans les 5-10 sec apres que le chien ait ete fait, ou quelque chose
> comme ca.

Ne surtout pas mettre des contraintes de temps. Si une personne se trouve
sur un reseau lent, il sera penalise. En programmation reseau, les temps
ne doivent servir que pour des timeout.

Sinon, pour les annonces, on peut effectivement partir du principe que le
client fait cette annonce spontanement. Si on fait cela, on est oblige de
mettre en place une couche supplementaire pour une horloge, pour savoir si
le client a bien fait son annonce avant le moment fatidique ou apres, le
moment fatidique etant un message du serveur.

Ceci est encore un exemple qui montre que l'on peut tout a fait avoir un
protocole comme tu dis, mais qui oblige a coder des trucs supplementaires
dont nous nous allons nous passer avec notre protocole synchrone ou le
client ne parle que quand on le lui demande (sauf exceptions car il y en a
tout de meme).

>
>> 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?
>
> Je ne reponds rien du tout, et le serveur ne doit pas etre traumatise
> par ca, de toute facon.

bah sauf que ca voulait dire que c'est a toi de jouer, car on a change le
mot-clef parce qu'on a rajoute un element au protocole et il a fallu
changer le mot-clef. Resultat, si tu ne reponds rien du tout, le serveur,
il attend.
Tu pourrais objecter qu'au bout d'un moment, il y a timeout, et que tu te
fais jeter. Ou alors qu'on peut detecter cela avec le numero de version du
protocole. Encore une fois, oui, on peut s'en sortir autrement. Mais il
est tellement plus simple que le client dise "j'ai rien compris a ce que
t'as dit", ce qui est d'ailleurs plus proche de la realite pour deux
personnes qui se causent.

>
>> 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.
>
> y}2}p
>
> Je ne reponds rien du tout, et le serveur ne doit pas etre traumatise
> par ca, de toute facon.

cf plus haut: tu peux bloquer le jeu.

>
>> Tant qu'on depasse pas les 1100 octets, c'est le meme cout, 2 ou 9
>> octets.
>
> C'est peut-etre le meme cout pour ethernet, ou un trame atm, mais pas si
> tu joues pas modem, un null-modem serie, etc.. etc.. Le mtu n'est pas la
> taille obligatoire de trame, mais bien _maximale_...

Par modem, oui, admettons. Mais que coutent 24 octets supplementaires dans
une partie, partie qui va durer 10 min? Ou 120 octets supplementaires si
tu heberges le serveur? En 56k, ca fait meme pas 1/10 de seconde! Moi,
j'appelle ca des economies de bouts de chandelles.

>
>> > 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.
>
> La encore, c'est peut etre mal ecrit. Ce qui est dit dans les pre-specs,
> c'est que l'approche _choisie_ a pour inconvenient d'etre un peu plus
> dure a implementer.

Laisse tomber, c'est moi qui ai mal lu. j'ai lu:
"protocole binaire: Un peu (un peu..) plus complique a implementer."
Il fallait lire "inconvenients (du protocole texte) : Un peu (un peu..)
plus complique a implementer."

Pour la ligne qui precede, concernant la bande passante, tu as aussi
raison, mais bon, a nouveau, entre 500 et 1000 octets (donc moins d'1k),
meme par modem, c'est ridicule comme difference surtout dans le cas d'un
systeme de jeu ou sur une partie de 10 min, tu vas avoir peut-etre 100k
(estimation vraiment subjective) qui va circuler en 10min.

Yves

>
> --
> Jeremie Koenig <address@hidden>
>
>
> _______________________________________________
> Maitretarot-devel-fr mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/maitretarot-devel-fr


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