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

[Jeremie Koenig]

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 ? 

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

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

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

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

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

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

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

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

-- 
Jeremie Koenig <address@hidden>