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

[Yves Mettier]

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

Oui, la coinche, le tas de merde, le quems...

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

Dans ces cas, oui, il y a un morceau d'asynchrone.
A nouveau, oublie l'implementation, select, threads et tout ca. Il s'agit
de causer du protocole, et effectivement, dans ce cas, il n'est pas
synchrone.

Nous avons deja prevu que le chat etait asynchrone. Il faut aussi
specifier les autres cas ou c'est asynchrone.

En fait, je crois qu'il faut carrement prevoir deux types de messages dans
le jeu, ceux qui sont synchrones et ceux qui ne le sont pas.
Je reste partisan d'avoir des messages synchrones, meme si on peut faire
du 100% asynchrone. En effet, pour ce qui est synchrone, si c'est
implemente dans le protocole, il n'y a pas de couche logicielle a rajouter
au dessus du protocole pour traiter cet aspect.

Par ailleurs, tu notes qu'il y a quand meme un gros probleme quand il
s'agit de traiter des cas ou la communication est asynchrone et que cela
fait partie du jeu: si t'as un serveur sur une machine, avec 3 joueurs
connectes en 1000Mb/s, et un autre connecte par un cable serie a sa
passerelle elle-meme connectee au serveur par une ligne RTC (56k) - je
prends des cas extremes volontairement -, celui qui est derriere son cable
serie aura du mal a coincher au bon moment avant que l'enchere monte.

Et la, j'ai une question que t'auras a resoudre: est-ce que tu penses
traiter ce probleme en ajoutant une couche logicielle (une horloge par
exemple), ou as-tu une idee pour mettre cela dans le protocole?

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

Bah oui et non.
Il y a differents points de comparaison. On peut le comparer du point de
vue de sa syntaxe: il y a quasiment que des points communs entre le tien
et le notre. On peut le comparer au niveau semantique: on est en train de
litteralement repomper tes variables (tu les appelles arguments). On peut
le comparer du point de vue traitement, et la, le tien favorise une
implementation asynchrone alors que le notre favorise clairement une
implementation synchrone (sauf exceptions)

Mais bon, il faut pas critiquer les comparaisons, il faut se piquer les
bonnes idees. Et pour l'instant, je crois qu'il n'y ait que nous qui ayons
pique des idees dans le tiens, et pas de contraire, ce qui est dommage.
Alors, quand est-ce que tu nous piques nos bonnes idees? (peut-etre qu'on
en a pas, c'est pour ca qu'on te pique les tiennes? :)

[...]

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

Non. De nouveau, la, tu mets une contrainte de temps qui n'est pas un
timeout.

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

De toute facon, on mettra ca en place. Pour l'instant, il y a une unique
exception qui est le chat, mais elle est la, et on fait ce qu'il faut
pour. Ensuite, pour tout ce qui est synchrone par nature (jouer une carte
a son tour et pas n'importe quand par exemple), on reste synchrone. Les
encheres comme les annonces sont synchrones.
En asynchrone, je ne vois guere que le fait de dire coinche, ou de gueuler
"menteur" au menteur etc. Arf, oui, dans la liste tout en haut, j'ai
oublie le menteur :)

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

Si tu dis "say dunno" au serveur, il sait tout de suite quoi faire et
connait exactement le probleme. Dans les autres cas, on peut prevoir un
timeout, ce qui ralentit les autres, ou le fait que le serveur te
redemande la meme chose si tu lui as repondu n'importe quoi (ca evite
d'interrompre une partie pour une simple faute de frappe - ceci sert
principalement au deboguage) etc.

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

Il est clair que ca n'empeche pas la necessite du timeout.

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

Si le but du client est de le bloquer, chaque programme mettra en oeuvre
les memes principes de protection, comme les timeouts. Ceci est hors
protocole en fait: c'est de la gestion d'erreur.
Si le client n'est pas mal intentionne, il est plus simple qu'il sache
expliciter son probleme: dans certains cas la resolution du probleme peut
ne pas etre la fin de partie prematuree.

[...]

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     -