Re: [Maitretarot-devel-fr] protocole

[Yves Mettier]

Bon, y'a philippe qui a fait n'importe quoi: j'ai recu ce courrier en
perso donc la ml l'a pas eu.
Je reponds quand meme, en ne supprimant rien.


> "Yves Mettier" <address@hidden> writes:
>
>> > "Yves Mettier" <address@hidden> writes:
>> >
>> >> Coucou!
>> >>
>> >> Nouvelle version du protocole, apres discussion avec Philippe
>> (hocwp).
>> >>
>> >> Principe: le serveur met a disposition des clients le contenu de
>> certaines variables. Les clients ont donc pour principe de demander
>> au serveur ou on en est, en fonction des besoins.
>> >> Entre autres, le serveur met une variable indiquant l'etat du jeu
>> (par exemple, le contenu de cette variable contient une valeur
>> indiquant que c'est au joueur 3 de jouer).
>> >>
>> >> De plus, le serveur doit pouvoir demander des choses au client
>> (exemple: "tu te bouge le cul et tu joue ta cartes, steup?").
>> >>
>> >> Le principe du jeu, ensuite, sera que chaque client est amorphe (a
>> moins qu'il ne veuille faire des choses par lui-meme). Et le
>> serveur envoie des requetes "balance-moi tel truc steup" au client
>> qui doit renvoyer ce qu'il faut.
>> >>
>> >> Pour la forme, le protocole de Jerome me plait bien. Il a juste un
>> inconvenient: c'est un systeme a base d'ordre et de valeur. Il nous
>> faut, pour avoir une bonne resistance aux pannes, un systeme a base
>> d'ordre, de clef et de valeurs.
>> >> Exemple:
>> >> client->serveur: SET carte_jouee 11
>> >> Ou alors:
>> >> serveur->client: INFO joueur1 11   (pour dire que le joueur 1 a
>> joue le 11 de carreau)
>> >>
>> >> Il nous faut donc inventer tout un vocabulaire pour cela. Mais ce
>> qu'il faut retenir, c'est que tout message envoye sur le reseau
>> sera compose d'un ordre, d'une clef et d'une valeur (meme si la
>> valeur doit etre ignoree :)
>> >>
>> >
>> > ok, donc si j'ai bien compris, pour le debut de partie, ça peut
>> donner un truc du genre :
>>
>> On parle du debut de la *partie*, parce qu'il y a des choses qui
>> precedent pour le debut de la *connexion*.
>>
> oui, il y a toute la partie etablissement de la connexion avant.
> Par contre l'envoi des Nicks et autre identification peut se faire par
> le protocole.

s/peut/doit/

>
>> >
>> > * le client reçoit ses cartes :
>> >
>> > serveur->client: SET carte_en_main 11 22 44 45 ...
>>
>> oui
>>
>> >
>> > * les encheres :
>> >
>> > serveur->client: DEMAND(?) enchere
>> >
>> > client->serveur: GET enchere_autres_joueurs
>>
>>
>> Pas clair, ce "DEMAND". "ASK" est meilleur.
>> Oui, ici, c'est plutot un cas exotique, qui peut arriver et que le
>> serveur doit savoir gerer.
>> Normalement, le serveur doit d'abord envoyer l'etat de encheres au
>> client, puis faire ce ASK. Et dans ce cas, la reponse normale du
>> client devrait etre un truc comme "SAY mon_enchere passe"
>>
>> D'ailleurs, je trouve ces mots-clefs sympa, ASK pour le serveur et SAY
>> pour le client. Ca nous rapproche de la realite. INFO pour le serveur
>> aussi, cf juste apres
>>
> oui, ça me va tres bien !
> DEMAND est long et pas trop approprie et la sequence ASK, SAY
> parait beaucoup plus logique.
>
>> > serveur->client: SET enchere_autres_joueurs b1 b2 b3 b4 b5
>> > (avec b1,... les encheres des autres joueurs)
>>
>> Ici, INFO est mieux. Sinon, oui, c'est ca.
>>
> OK, tres bien !
>
>> >
>> > client->serveur: SET enchere 2
>>
>> Non. Justement, ici, on reproduit le pb du protocole version 0.1
>> (c'est bien 0.1 la version actuelle?) Si le serveur annonce les
>> encheres des autres joueurs, il ne demande rien au client. Dans ce
>> cas, le client doit fermer sa gueu... sa sortie :)
>>
>> Pour les encheres, il faut s'attendre plutot a ceci:
>>
>> S->C: INFO encheres b1 ? ? ? ?
>> S->C: INFO encheres b1 b2 ? ? ?
>> S->C: ASK enchere
>> C->S: SAY b3
>> S->C: INFO encheres b1 b2 b3 b4 ?
>> S->C: INFO encheres b1 b2 b3 b4 b5
>>
> oui, tres bien sous cette forme !
>
>> D'ailleurs, je m'apercois qu'il existe un bug dans le serveur (et dans
>> les clients actuels?): si deux joueurs font une enchere, c'est le
>> deuxieme (qui a surencheri, forcement) qui fait le jeu. Dans la regle
>> du jeu, le premier devrait pouvoir surencherir ou passer. ceci n'est
>> pas implemente dans maitretarot-0.1.1.
>>
> oui, ce n'est implementé nul part :(
> va falloir rajouter ca dans le protocole, et comme c'est
> le serveur qui engage les conversation, il sera facile de
> redemander a un client s'il veux surencherir.

Oui.
Tiens, pour rappel, surtout pour jerome parce que sur irc, j'ai ete
incapable de donner la raison veritable du changement de protocole. On met
un systeme ou il y a des ordre afin que le serveur initie tout echange et
que le client reponde si besoin. Cela permet de ne pas avoir un caractere
sequentiel au protocole. Et du coup, et c'est la la raison veritable du
changement, on peut donc rajouter des morceaux au protocole du cote
serveur qui peuvent ne pas etre encore implementes du cote client, et que
ca fonctionne encore. Avec un protocole sequentiel, c'est impossible
puisqu'un ajout ou un retrait brise la sequence.

Et du coup, On implementera tout de suite une reponse "I don't know" du
cote client pour renvoyer au serveur si le client ne reconnait pas une
fonctionnalite (pas encore implementee du cote client).

>
>> >
>> >
>> > etc...
>> >
>> > et la même chose pour les joueurs qui attendent...
>>
>> ... et la meme chose pour les joueurs qui attendent evidemment.
>>
>> >
>> > enfin, il y a moyen de simplifier un peu (exemple le
>> > serveur envoi les encheres des autres joueurs au moment
>> > ou il fait la demande des encheres).
>>
>> Non. C'est possible, mais cela suppose que le client sait decoder
>> quand il doit faire son enchere en fonction de la valeur d'une clef.
>> Je prefere que le client ne reponde qu'a certains messages en fonction
>> de la commande, jamais en fonction ni de la clef ni de la valeur de la
>> clef.
>> Typiquement, un joueur devra toujours repondre a une commande ASK et
>> jamais a une commande INFO.
>>
> oui, c'est impeccable sous cette forme => on aura que
> des sequences S->C : ASK;  C->S : SAY
> ou juste S->C : INFO
>
>>
>> Question: doit-on implementer une commande ACK, reponse du client au
>> serveur lorsque le serveur envoie une commande INFO?
>> Avantage: ca permet au client d'en profiter pour demander autre chose
>> s'il en a besoin, puisque le client n'a le droit de parole qu'en
>> reponse a une demande du serveur. Mais est-ce necessaire?
>> Inconvenient: Ca nous rajoute du trafic reseau quasi inutile. Quasi
>> inutile ou vraiment inutile? Meme si c'est inutile, vu que
>> l'application n'est pas specialement gourmande en bande passante,
>> doit-on economiser ici?
>>
> Ben je ne sais pas si ca sert a grand chose.
> Quand le serveur fais un INFO puis un ASK, on devrai avoir
> prevu tout ce qu'a besoin le client dans le INFO.
> Ca va compliquer les choses si le client peut/doit demander
> des choses non prevues.

Ca peut compliquer du cote serveur. Du cote client, non, au contraire.
Mais ca, c'est a la fois une fonctionnalite ET une resistance au erreurs
de protocole. Donc faut l'implementer, meme si le client ne s'en sert pas.

>
>>
>> Autre remarque: le chat. A mon avis, alors que tout le reste est
>> synchrone (le client ne parle que si le serveur a fait une demande),
>> le chat est asynchrone. On peut le faire passer via une commande CHAT.
>> Cela devrait un poil compliquer les clients qui veulent gerer cette
>> fonctionnalite future. Cela devrait beaucoup compliquer le serveur qui
>> du coup doit ecouter sur ses sockets a tout moment. Je suis assez pour
>> implementer un support possible de cette fonctionnalite, car si on ne
>> prevoit pas cette fonctionnalite a l'avance, il faudra recoder le
>> serveur quasi en entier si on veut implementer une fonctionnalite
>> asynchrone, quelle qu'elle soit. Mais est-ce vraiment la peine pour le
>> chat?
>> Il y a irc, icu et d'autres protocoles pour discuter en meme temps. Un
>> tel protocole rajoute peut-etre des problemes de securite (quoiqu'a
>> premiere vue je n'en vois pas). Bref, on verra ca plus tard. Ne nous
>> fermons pas les portes :)
>>
> La commande CHAT (ou une autre) est peut etre interressante
> si on doit communiquer de maniere asynchrone, mais je me
> demande si ca ne complique pas enormement les choses, alors
> qu'il suffirai d'ouvrir un autre port pour faire du chat
> ou des communication asynchrone.

On va pas quand meme utiliser 2 sockets!?

> Est-ce vraiment handicapant si on ouvre 2 sockets (exemple port
> 2551 et 2552) l'une pour le protocole, l'autre pour les
> communications asynchrone ?

Non, mais dans ce cas, je fais aussi un malloc des 3/4 de la memoire vive,
comme ca, je suis sur d'avoir assez de memoire tout le temps.

>
>
> Des que j'ai le temps, je redige le protocole en partant
> des fonctions et en me bassant sur les trois actions
> S->C : ASK, C->S : SAY et S->C : INFO.

OK.

Faudra aussi clairement remarquer que:
INFO n'implique jamais de reponse de la part du client
ASK implique toujours une reponse de la part du client si c'est le serveur
qui l'envoie. Si c'est le client, le serveur est prie de repondre.
SAY est une reponse a ASK

Il faut une commande pour dire "I don't know". DUNNO ?

Yves

>
>
> Philippe
>
> --
> (    )
>  ~oo~         Philippe Brochard    <address@hidden>
>   .. Gnu!                           http://hocwp.free.fr
>   / =\   \=
>  -   -    -   -=-= http://www.fsf.org/home.fr.html =-=-


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