Re: [Maitretarot-devel-fr] nouveau protocole

[nico]

J'ai lu en diagonal.

On Mon, 16 Dec 2002 20:33:34 +0100
Yves Mettier <address@hidden> wrote:

> On 16 Dec 2002 19:00:30 +0100
> philippe brochard <address@hidden> wrote:
> 
> > 
> > Bonjour a tous,
> > 
> > suite a une discution avec Yves sur IRC, nous avons decider
> > de changer de protocole pour faire en sorte que la partie
> > gestion de l'ordre du jeu soit initiee par le serveur et
> > non pas dans le client (ou la lib client) comme c'est le
> > cas actuelement.
> > 
> > Pour cela, voila la liste des fonctions dont ont besoin
> > les clients :
> > 
> > Vocabulaire :)
> >   get : le client a besoin d'une information du serveur
> >   set : le client donne une valeur au serveur.    
> 
> Euh, vu que le client deviendra une sorte d'objet manipule par le
> serveur, c'est plutot le contraire.
> Exemple: quand le serveur fait appel a get_hand_cards() du client, il
> ne demande pas au client les cartes. Il fait le contraire: il les
> fournit.
> 

send/request ?

A chaque intant, il faut savoir lesquels sont valides. D'un coté comme
de l'autre.

Si le client peut envoyer des requests, il n'est pas du tout piloté par
le server. 

Cela donne un format request:

ACTION paramètres ... (à la tcl)

 et un format donné
toto = titi
ou 
toto = {toto,tutu,pt,a6}

> D'autre part, get et set sont des mots generalement associes a des
> variables. Or d'apres notre discussion, on ne travaille pas avec un
> systeme de variables mais un systeme de commandes (on avait parle de
> procedures a cause de l'analogie avec les rpc).
> Le vocabulaire devient donc du vocabulaire d'action, comme compute,
> exec, init, etc.
> 
> > 
> > 
> > Identification :
> > --------------
> > 
> >   * {Nick, } set_identity_client (void)
> > 
> >   Cette fonction est appele au debut pour realiser(?) la connexion
> >   et informer le serveur sur le client qui vient de ce connecter.
> >   Les parametres de version ne sont pas primordial pour le client
> >   mais il peuvent etre utiles.
> > 
> > 
> >   * {void} get_resume_client (place, nombre_joueur, nick_client1,
> >       nick_client2, nick_client3, ..., score1, score2, score3, ...)
> > 
> >   Cette fonction permet d'informer le client sur les autres joueurs.
> >   la bornes nick_client3 depend du nombre de joueur, elle peut aller
> >   jusqu'a nick_client5 dans le cas d'un jeu a 5 joueurs ou
> >   nombre_joueur = 5.
> >   Les score1 a 3 (4 et 5) sont les scores totaux des precedentes
> >   parties.
> > 
> > 
> > Debut du jeu :
> > ------------
> > 
> >   * void get_hand_cards (c1, c2, c3, c4, ..., c18)
> >   
> >   Le client recoit les cartes qu'il a en mains (c1, c2...).
> >   Le parametre c18 peut varier de c15 a c24 suivant un jeu a 5
> >   joueurs
> >    ou 3 joueurs.
> 
> 24 parametre.
> Si on est a 4, les 6 derniers seront undef. Si on est a 5, ce seront
> les 9 derniers a etre a undef.
> 
> > 
> > 
> > Encheres :
> > --------
> > 
> >   * {enchere} set_bid (e1, e2, e3, ...)
> > 
> >   Cette fonction est appelee si le client doit faire une
> >   enchere.
> >   Le serveur lui fourni les encheres des autres joueurs
> >   (e1,e2,e3,e4,e5 enchere des clients 1 2 3 4 5 suivant le
> >   nombre de joueurs) 
> > 
> > 
> >   * void other_bid (place, e1, e2, e3 , ...)
> > 
> >   Cette fonction est appelee quand un autre joueur est en
> >   train de faire sont enchere. Le serveur fourni la place du
> >   joueur qui est en train de faire sont enchere, ainsi que les
> >   encheres deja faites. 
> > 
> > 
> > Chien :
> > -----
> > 
> >   * {c1, c2, ..., c6} set_chien (pc1,pc2,...,pc6)
> > 
> >   Cette fonction est appellee si le client doit faire un chien
> >   (petite ou garde).
> >   Le serveur fourni les cartes du chien original (pc1...pc6).
> >   Le client renvoit les cartes du chien qu'il a fait (c1...c6).
> >   Les parametres c6 et pc6 peuvent etres c6,pc6 pour un jeu a 3
> >   ou 4 et c3,pc3 pour un jeu a 5 joueurs.
> >   Tant que le chien n'est pas valide, le serveur demande au client
> >   de faire un chien.
> > 
> > 
> >   * void chien_valide (c1, c2, ..., c6)
> > 
> >   Cette fonction est appellee si le chien fait par le client (avec
> >   set_chien) est valide. Elle permet au client de savoir que le
> >   serveur a accepte son chien.
> > 
> > 
> >   * void other_set_chien (place, c1, c2, ..., c6)
> > 
> >   Cette fonction est appellee quand un autre joueur est en train
> >   de faire son chien. Le serveur fourni la place du joueur qui est
> >   en train de faire son chien et le chien original.
> >   Meme reflexion que precedement sur le parametre c6 suivant le
> >   nombre de joueur. (Ceci toujours dans le cas d'une petite ou d'une
> >   garde).
> > 
> > 
> >   * void no_chien (void)
> > 
> >   Cette fonction est appellee si les clients n'ont pas a faire de
> >   chiens(garde sans, garde contre).
> > 
> 
> Manque les annonces ici.
> Tu peux deja fournir le proto des procedures, voire les implementer,
> meme si les arguments seront initialement ignores et une valeur undef
> est renvoyee.
> J'ai vu que c'est plus bas dans le mail.
> 
> > 
> > Jeu des cartes :
> > --------------
> > 
> >   * {card} set_card (lc1, lc2, lc3, ...)
> > 
> >   Cette fonction est appellee chaque fois que le client doit jouer
> >   une
> >    carte.
> >   Le serveur fourni les cartes du tour precedent en parametre (lc3
> >   varie en fonction du nombre de joueur), le client renvoit la carte
> >   qu'il veut joueur.
> >   Tant que la carte n'est pas valide, le serveur demande au client
> >   de rejouer une carte.
> > 
> >   
> >   * void card_valide (card)
> > 
> >   Cette fonction est appellee si la carte card jouee par le client 
> >   (avec set_card) est valide.
> >   Elle permet au client de savoir que la carte card a ete acceptee
> >   par le serveur.
> 
> ici, quel doit etre l'algo a mettre en place si la carte est non
> valide?
> 
> > 
> > 
> >   * void other_set_card (place)
> > 
> >   Cette fonction est appellee quand un autre joueur est en train de
> >   choisir une carte a jouer. Le serveur fourni la place du joueur
> >   qui est en train de joueur.
> 
> et la carte, non?
> 
> > 
> > 
> >   * void end_of_turn (c1, c2, c3, ..., lc1, lc2, lc3, ...)
> > 
> >   Cette fonction est appellee a la fin d'un tour. le serveur fourni
> >   les cartes jouees dans le tour (c1...) ainsi que les cartes du
> >   tour precedent (lc1...).
> >   Les bornes c3 et lc3 dependent du nombre de joueur.
> > 
> > 
> >   * {announce} set_announce (a1, a2, a3, ...)
> > 
> >   Cette fonction est appellee lorsque le serveur a besoin de
> >   connaitre les annonces des clients (juste apres le 1er tour, il me
> >   semble). Il fournit les annonces des autres joueurs et le client
> >   renvoie son annonce (s'il veut en faire une).
> > 
> > 
> > Fin de partie :
> > -------------
> > 
> >   * {replay} end_of_game (contract, win, score, oudlers, 
> >                           sc1, sc2, sc3, ..., chien1, chien2,
> >                           chien3, ...)
> > 
> >   Cette fonction est appellee en fin de partie si le jeu c'est
> >   deroule normalement ou que tout le monde a passe.
> > 
> >   Le serveur fourni :
> >     contract : le contrat du preneur
> >     win : TRUE si le preneur a gagne, FALSE autrement
> >     score : le score du preneur pour la partie
> >     oudlers : le nombre d'oudlers du preneur
> >     sc1, sc2, sc3 ... : les scores totaux de tous les joueurs
> >      (score de la partie ajoute aux scores precedents, pour chaque
> >      joueur). sc3 peut varier en fonction du nombre de joueurs.
> >     chien1, chien2, chien3, ... : les cartes dans le chien.
> >     chien3 peut varier en fonction du nombre de joueurs.
> > 
> >   Si tout le monde a passe, contract vaut BID_PASSE et les cartes du
> >   chien sont affectees, les autres valeurs sont non definies.
> > 
> >   Le client renvoi replay qui vaut TRUE si le client veut rejouer ou
> >   FALSE dans le cas contraire.
> > 
> > 
> > Cas particulier :
> > ---------------
> > 
> >   * void normal_close (void)
> > 
> >   Cette fonction est appellee si la connexion a ete fermee
> >   normalement(en fin de partie quand quelqu'un a dis qu'il voulait
> >   quitter le jeu)
> > 
> > 
> >   * void lost_connexion (void)
> > 
> >   Cette fonction est appellee dans le cas ou il y a eu une
> >   deconnexion. Elle permet d'informer les clients que le jeu ne se
> >   deroule plus normalement.
> > 
> > 
> > 
> > Voila, pour l'instant ces fonctions sont faites dans libmt_client.
> > Et donc avec le protocole actuel c'est la libmt_client qui demande
> > au client de faire telle ou telle action (donc la libmt_client
> > implemente le meme protocole que le serveur).
> > 
> > Avec le nouveau protocole, ce serai bien de faire en sorte que ce
> > soit le serveur qui demande au client de faire telle ou telle
> > action. La libmt_client n'etant la que pour etablir la connection,
> > gerer le reseau et informer le client de ce que le serveur lui
> > demande. Dans ce cas, seul le serveur serai au courant du
> > deroulement du jeu, les clients ne faisant que repondre a ce que le
> > serveur leur demande(ie: il n'y aurai plus qu'une seule
> > implementation du protocole : celle du serveur).
> 
> Ceci n'etait pas le protocole mais un inventaire des procedures qui
> sont ou seront dispo chez tout client qui se veut compatible avec
> maitretarot.
> 
> Il faut donc maintenant...
> 1/ definir le protocole.
> Pour une fonction A qui prend comme arguments arg1, arg2...argn et qui
> renvoie r1, r2...rn, avec argi et ri de type int ou string, il faut
> pouvoir encoder tout cela dans un format independant du nom de la
> procedure, du nombre et du type des arguments et des valeurs de
> retour.
> 
> 2/ implementer le protocole
> Le serveur doit generer les commandes au format du protocole,
> recuperer les valeurs de retour et les interpreter
> Le client doit interpreter les commandes et appeler les fonctions
> associees, puis encoder les valeurs de retour suivant le format du
> protocole
> 
> 3/ faire de la verification d'erreur et implementer un sous-protocole
> de traitement d'erreur (que faire si le client ne renvoie rien, ou
> renvoie des donnees insuffisantes, trop nombreuses ou au mauvais
> format...?)
> 
> 
> 
> Quelques remarques...
> 
> Nous abandonnons le format xml un moment envisage. C'est trop complexe
> a mettre en oeuvre par rapport au gain que ca apporte.
> 
> Le protocole, a un niveau tres bas, disons couche 1, consistera a
> envoyer des paquets. Un paquet est consitue de sa longueur (4 octets)

vous ne faites pas confiance au read ?

> puis d'une chaine de caracteres representant le contenu du paquet.
> Puis il faut definir comment on code les arguments string
> ou int, ainsi que des constantes comme UNDEF. Et definir comment on
> code une commande.
> La couche 2 consiste a utiliser ce codage pour envoyer des commandes
> et des resultats
> La couche 3 coordonne tout cela, a savoir comment on fait pour
> dialoguer.
> 
> 
> La couche 1 est deja codee.
> Ci-dessous, une proposition de codage des differents elements
> la couche 2 est encore d'ordre reseau puisqu'elle ne tient pas compte
> du contenu de ce qui est envoye.
> la couche 3 est d'ordre applicative.
> Et evidemment, la couche 4 dont je n'ai pas parle, c'est les
> fonctions, qui sont propres a chaque client.
> 
> 
> proposition de codage des differents elements:
> - tout entier doit etre mis entre parentheses
> - toute chaine de caracteres doit etre mise entre guillemets. Comment
> coder un guillemet? On le double, on lui met un antislash devant, ou
> on trouve autre chose?

Anti slash ! windows et son doublement, c'est un vrai calvaire va savoir
ce que """"" va te rendre !

> - une valeur non definie sera 0. Remarque: 0 est donc different de
> (0).
> - tout nom de procedure, vu qu'il est defini et fait partie de
> l'ensemble des noms de procedures, n'a pas besoin d'un codage special.
> Simplement, pour les noms des procedures, nous n'utiliserons que des
> caracteres alphanumeriques (et le _).
> 
> Jusqu'ici, on peut encore utiliser un parser fait avec du C.
> Pour la couche 2, si on va plus loin dans ce langage qu'on est en
> train de definir, il faudra utiliser le parseur bison (yacc).
> Mais on peut aussi tenter quelque chose de simple. A voir...
> 
> Bon, qui se devoue pour extraire les elements stables de cette
> discussion et la mettre en format docbook dans un fichier sgml?
> 

euh...
nicO

> Yves
> 
> 
> 
> 
> -- 
> - Homepage    - http://ymettier.free.fr  | CMG - http://www.cmg.com -
> - GPG key     - http://ymettier.free.fr/gpg.txt                     -
> - Maitretarot - http://www.nongnu.org/maitretarot                   -
> - GTKtalog    - http://www.nongnu.org/gtktalog                      -
> 
> 
> 
> _______________________________________________
> Maitretarot-devel-fr mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/maitretarot-devel-fr
> _____________________________________________________________________
> Envie de discuter en "live" avec vos amis ? T_l_charger MSN Messenger
> http://www.ifrance.com/_reloc/m la 1_re messagerie instantan_e de
> France