maitretarot-devel-fr
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rep:Re: [Maitretarot-devel-fr] nouveau protocole


From: Yves Mettier
Subject: Re: Rep:Re: [Maitretarot-devel-fr] nouveau protocole
Date: Tue, 17 Dec 2002 22:39:21 +0100 (CET)

> Si tu copie les RPC tu n'es pas du tout stateless et tu va jouer avec
> leur énorme problème.

1/ je ne copie pas les RPC, je m'en inspire.
2/ je ne suis pas stateless et on s'en fiche, cf les mails precedents.

>
> Quand tu fais une modification d'état (un write == send), tu envoie les
> paramètres avec la commande. C'est simple, c'est facile,...

Je ne fais pas de modifications d'etats. j'execute des commandes a distance.

>
> Si tu fais une lecture d'état(read == get). C'est beaucoup plus
> complexe.
>
> Client.-.Server
> req....->....
> ......<-.answer
>
> Donc, le client se mets en attente d'une réponse, qui peut ne jamais
> venir, autre chose peut arriver...etc.. (dans un vrai rpc, rien d'autre
> que la réponse ne peut arriver, c'est donc plus simple)

Bah la, c'est comme les RPC, ce qu'on va faire. Tout va bien.

>
> Si tu fais une "request", l'autre répond par un "send". Mais le client
> n'attends pas de réponses (non bloquant). Il tient ensuite compte de
> tous les messages qui arrivent.

J'ai pas tout suivi, la.
Le serveur envoie une commande au client, avec des arguments, et attend en
retour le resultat.

>
> Cela se ressemble beaucoup et c'est sans doute ce que tu allais
> effectivement codé, mais c'est fondamentalement différents d'un RPC.



>
> Le fait de balancer tous l'état permet de sauver des parties. Mais bon
> 8k, cela commence à faire (8k ?? tu comptes quoi ? 18 cartes (~54) +
> 18*4 cartes max (72*3=216) dans les plis + chiens (6*3=18) + enchère
> (~5) + nicks (4*10=40) = 333 octets, on est bien loin du kilo octets et
> cela laisse toujours de la marge pour être humain readable! ) ! Comment
> tu trouves tes 8 k ?

kill -SIGUSR1 <pid de maitretarot>
Puis ls -l <le fichier genere>
Resultat: 8k chez moi.

Divise par contre par 4 vu que c'est pour les 4 joueurs, les 8k. Retire
quelques commentaires, et on arrive quand meme a 1k je pense quand meme.

Et remarque que c'est le serveur qui connait l'etat de la partie, et que
c'est le serveur qui sauve. Le client n'y est pour rien, donc on n'envoie
pas l'etat de la partie au client.

Au mieux, si le client est deconnecte, le serveur va tenter de reconnecter
le client (la, on reflechira bien a cause des nombreux pb de securite que
ca entraine), et quand il est reconnecte, le serveur lui envoie les cartes
qu'il doit avoir dans les mains, et peut-etre aussi (attention a la
triche) les cartes qui ont ete jouees. Mais pas grand chose de plus.

Yves


>
> nicO
>
> -----Message d'origine-----
> De: "Yves Mettier" <address@hidden>
> A: <address@hidden>
> Date: 17/12/02
> Objet: Re: [Maitretarot-devel-fr] nouveau protocole
>
>
>> "Yves Mettier" <address@hidden> writes:
>>
>>> > Globalement, le truc le plus simple, c'est : en cours de jeu, le
>>> serveur envoie toutes les données (après que chaque joueur est joué)
>>> qu'il a avec un flag "à toi de jouer". Comme ça, il n'y a qu'un seul
>>> type de message.
>>>
>>> T'es violent, toi.
>>> Ca fait quasi 8k dans l'etat actuel des choses. Et tu voulais faire
> ca
>>> en udp!?
>>>
>>>
>>> >
>>> > On mets un timeout sur la réponse, tu renvoie 2-3 fois, puis après
>>> tu envoie le paquets à tous avec un flags en "erreur". C'est ça le
>>> vrai stateless:)
>>>
>>> On laisse tomber le stateless.
>>> On va s'inspirer des rpc en fait.
>>>
>>> > Il faut envoyer ses cartes restant, des flags (erreur ou pas, son
>>> tour de jouer ou pas,...), les plis (l'équipe du preneur puis
>>> l'autre), le paris, les annonces, tout quoi. 1 seul message avec
>>> l'état dedans (erreur ou pas, etc...)
>>>
>>> Outre le fait qu'on laisse tomber le stateless, sachant
>>> qu'actuellement, ca fait environs 8k et y'a pas de format, si on le
>>> formate, ca risque de prendre encore plus!
>>>
>> on peut faire les 2 :
>>
>>   * la version avec juste les fonctions quand tout va bien
>>
>>   * tout l'etat (depuis le debut) quand un client est paume
>>         (ex apres une deconnexion).
>
> On fonctionne avec un systeme de procedures, pas avec un systeme de
> variables.
> Donc on aura une procedure pour envoyer tout l'etat du systeme et
> reinitialiser le client a la volee, c'est evident.
> Mais devra-t-on appeler cette procedure avant tout appel d'autre
> procedure? je n'en vois pas l'interet.
>
> Yves
>
> --
> - Homepage - http://ymettier.free.fr - http://www.cmg.fr -
> - GPG key  - http://ymettier.free.fr/gpg.txt             -
> - MyAM     - http://www.freesoftware.fsf.org/myam        -
> - GTKtalog - http://www.freesoftware.fsf.org/gtktalog    -
>
>
>
>
>
>
> _______________________________________________
> Maitretarot-devel-fr mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/maitretarot-devel-fr
> _____________________________________________________________________
> GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321
> (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagné.
> Règlement : http://www.ifrance.com/_reloc/sign.sms
>
> _____________________________________________________________________
> GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321
> (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagné.
> Règlement : http://www.ifrance.com/_reloc/sign.sms
>
>
>
>
> _______________________________________________
> Maitretarot-devel-fr mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/maitretarot-devel-fr


-- 
- Homepage - http://ymettier.free.fr - http://www.cmg.fr -
- GPG key  - http://ymettier.free.fr/gpg.txt             -
- MyAM     - http://www.freesoftware.fsf.org/myam        -
- GTKtalog - http://www.freesoftware.fsf.org/gtktalog    -







reply via email to

[Prev in Thread] Current Thread [Next in Thread]