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

[Jeremie Koenig]

On Fri, Jan 17, 2003 at 11:30:59AM +0100, Yves Mettier wrote:

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

Mais je ne crois pas que jouer aux cartes soit dans tous les cas
integralement synchrone.

Exemple: tu connais peut-etre la coinche (en tout cas sinon tu loupes
quelque chose ;). C'est une belote avec des encheres un peu plus
evoluees. On annonce un score et une couleur d'atout. Et a tout moment
pendant les encheres chacun peut coincher (taper sur la table) uen
enchere de l'equipe opposee. Ca a pour effet d'arreter les encheres et
de multiplier le score que vaut la partie par 2. L'equipe adverse peut
surcoincher, ca multiplie par 4.

Pour implementer ca (tout comme le chat), il faut de toute facon avoir
un select() au milieu du code. (au pire des threads..) Le protocole ne
peut pas etre synchrone pour ce genre de cas.

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

Il est quand meme un peu excessif de conmparer un protocole qui est (si
j'ai bien compris) sequentiel, synchrone, etc... a celui que j'ai pondu
tu ne crois pas ?

> Donc la non, on connait deja ce genre de protocole, et on veut faire autre
> chose.

Moi aussi je te rassure ;)

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

Oui, d'ailleurs ils _doivent_ servir pour des timeouts.

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

En fait, je voyais ca plutot comme ca : le moment fatidique est le
premier pli du jeu, et on ne peut pas jouer pendant un certain temps
(configurable, de l'ordre de 5 ou 10 secondes, et si quelqu'un a des
delais reseau comme ca...) apres que le chien ait ete fait.

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

Exceptions qui vous obligerons a mettre en place du code de traitement
asynchrone.

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

Mais, si j'avais un client bugge ou mal intentionne qui ne repondais pas
de confirmation, de "say dunno" ou je sais pas quoi, le probleme serait
exactement le meme. Et le serveur doit de toute facon pouvoir gerer ces
cas. (il ne doit pas etre traumatise).

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

C'est peut-etre apparemment plus simple, mais il faudra de toute facon
un timeout (si on veut faire les choses bien, avec votre proto comme
avec le mien).

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

cf plus haut: tu peux le bloquer avec votre systeme aussi.

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

Je disais pas qu'il fallait le faire (d'ailleurs je n'ai jamais eu
l'intention de faire ces economies.) C'etait juste des remarques a lo
con de puriste qui pinaille ;)

-- 
Jeremie Koenig <address@hidden>