Re: [Maitretarot-devel-fr] nouveau protocole

[Yves Mettier]

> -----Message d'origine-----
> De: "Yves Mettier" <address@hidden>
> A: <address@hidden>
> Date: 18/12/02
> Objet: Re: Rep:Re: [Maitretarot-devel-fr] nouveau protocole
>
>
>> On Tue, 17 Dec 2002 22:39:21 +0100 (CET)
>> "Yves Mettier" <address@hidden> wrote:
>>
>>>
>>> > 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.
>>>
>>
>> Stateless permet de régler les problèmes en cas d'erreur mais bon...
>
> Stateless implique un etat.
> Or il n'y a pas d'etat au niveau du client.
> Comment veux-tu faire?
>
>>>>Ouarch ! Evidement qu'il y a des états dans le client ! Sinon, le jeu
> n'avancerait jamais. Tu dois mélanger la notion d'état dans ton
> protocole et celui dans l'application. Un changement d'état veut dire
> que le client n'ai pas dans le même état avant qu'après le message. CEla
> parait idiot, mais lorsque le client joue une carte, il change d'état,
> il a modifer des varaibles internes. Tu peux lui demander 15 fois son
> nick, il sera toujours dans le même état. Demande lui 15 cartes, cela
> n'ai pas la même chose ! La notion "d'action" n'apporte vraiment pas
> grand chose.

Tout ce dont tu me parles est dans le serveur.
le client, s'il le veut, pourra se creer ses propres etats a partir des
infos que le serveur lui donne. Mais il pourra aussi ne pas se les creer.
Ainsi, dans mt_dolphin_ia, il est probable qu'il n'y ait pas d'etats
puisque la carte a jouer est jouee au hasard.

>
>>
>>> >
>>> > 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.
>>>
>>
>> :) Certe mais 90% du temps tu changes son états (donne un carte,
>> récupère une carte,...) ce qui différent de lire le nick (tu changes
>> rien dans le client)
>
> donner une carte et recuperer une carte ne sont pas des etats mais des
> actions.
>
>>>>Si , ce sont des actions qui modifie l'état (le client n'ai pas dans
> un état (justement) identique après l'execution de l'action).

L'etat du client, si tu en fais un, n'a pas d'importance pour le bon
deroulement du jeu.

>
> Si vraiment tu tiens a tes etats, ils seront 100% dans le serveur, et
> aucun client n'aura acces aux etats.
>
>>>>C'est totalement impossible car hors control de libmaitretarot.

gni?
Justifie toi, parce que c'est ce que nous faisons pourtant!

>
>>
>> Tu considères en réseau qu'il est déjà difficile d'avoir l'ordre
> correct
>> des paquets donc imagine le problème de considérer cohérent d'envoyer
> un
>> paquet et de garantir de recevoir la réponse.
>
> On utilise tcp/ip, donc ce que j'envoie est exactement ce que je recois
> (sauf erreur signalee par la pile TCP/IP)
> Donc ce probleme ne se pose pas.
>
>>>>En tout cas, cela aide.
>
>>
>> Le principe de request/send permet d'éviter cela. Mais bon, je me bats
>> peut-être que pour des mots, là.
>
> J'ai l'impression que tu veux refaire un protocole au dessus d'IP a la
> place de TCP.
>
>>>>Le problème est la reprise sur erreur, l'erreur n'étant pas forcément
> dû au réseau.

dans 99% des cas, il suffira de rebalancer l'ordre, en precisant que ce
n'est pas un nouvel ordre mais le precedent, renouvele.
Le 1% restant est la deconnexion, qui la se traite via la reconnexion,
reinitialisation du client et on renouvelle l'ordre aussi.

>
>>
>>> >
>>> > 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.
>>>
>>
>> Non, tout va pas bien. Les RPC étaient jugé assez merdique
>> "théoriquement" certe (je n'ai pas "pratiqué" les bétises). Mais les
>> arguements semblait bon. Je peux retrouver mes cours de DEA si tu
> veux.
>
> arf.
> 1/ on ne va pas utiliser les RPC
> 2/ maitretarot et ses clients ne sont pas adaptes aux RPC parce qu'avec
> les RPC, on supposerait que les clients ne font que du calcul. C'est
>
>>>> ??? Cela simule des appelles de fonctions distante avec des
> arguments qui ne sont pas des pointeurs : tu fais ce que tu veux avec !

Oui, c'est ce que nous sommes en train de mettre en place. Relis les
precedents mails pour voir comment on va mettre ca en place.

> peut-etre vrai pour les IA. C'est archi faux pour les IHM qui elles font
> d'autres taches en plus comme de l'affichage. Les RPC ne sont pas du
> tout adaptees.
>
> On se contente simplement de s'inspirer des RPC.
>
>>>>Mouais. Mais suite aux cours de DEA, j'avais intégrer que RPC
>>>> =plein_de_problème_subtile+emmerde_assuré

Bah indique ces problemes, parce que vu qu'on se contente de s'inspirer
des RPC sans les copier, il y aura deja pas mal de problemes_subtiles
evacues.
Ceux qui restent, on va se les prendre dans la figure: vaudrait mieux
qu'on soit au courant!

>
>>
>>> >
>>> > 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.
>>>
>>
>> La question est : attend il uniquement ce résultat ou une autre
> demande
>> ou setting est également possible. Tu semblait dire que oui dimanche.
>
> Dimanche, on parlait de machines a etats, puis de stateless.
> Puis dimanche soir, avec Philippe, on a abandonne ce systeme et on est
> passe a un systeme de partage de variables. Pour finalement encore
> abandonner cela et prendre l'idee des RPC.
> DOnc oublie ce qui a ete dit dimanche.
>
> Lorsque le serveur envoie une commande a un client, il attend uniquement
> le resultat de la commande.
>
>>>>Type RPC donc.

oui

>
> Pour illustrer cela, si on ne faisait pas un jeu en reseau, il faudrait
> utiliser dlopen. On est en reseau: il faudra creer un jeu de fonctions
> qui feront plus ou moins (ne me prend pas au mot stp) un dlopen via le
> reseau.
>
>>
>>> >
>>> > 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.
>>>
>>
>> Sans doute le codage des carte sur 32 bits qui revienne que je compte
>> pour 3 en ASCII (2 chiffres + le séparateur).
>>
>>> 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.
>>>
>>
>> Je pense aussi mais bon on revient dans le MTU.
>
> Ca, c'est pour UDP. Nous, on va bosser en TCP. Ca, c'est peut-etre un
> des rares trucs qui ont ete dit dimanche et qui n'ont pas change.
> Justement a cause de ce pb de MTU.
>
>>>>Je disais MTU par rapport au nombre de paquets transferés (physique)
> en rapport au performance même en tcp.

N'oublie pas que vu le trafic reseau engendre par maitretarot, les
performances reseau ont vraiment tres peu d'importance.
D'autre part, *c'est un scoop*, vu le systeme qu'on est en train de mettre
en place, en s'inspirant des RPC, il sera envisageable par la suite de se
passer du reseau et d'utiliser dlopen a la place le la couche reseau. Mais
bon, ceci est vraiment pour plus tard: on a d'autres chats a fouetter.

>
>>
>>> 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.
>>>
>>
>> ??? Il faudra bien pour relancer la partie.
>
> Pourquoi?
> Un client n'a pas a connaitre les cartes des autres clients!
>
>>>>Tu veux dire que chaque client devrait aussi sauver son état en plus
> du serveur ! Un peu balèze comme méthode. Je prèfairait que le client
> reconstruise son état avec des infos du serveurs qui pourrait aussi
> servir pour la reprise d'erreur.

Je veux dire que le client reconstruit son etat avec les infos du serveur.
Libre a lui de sauver ce qu'il veut aussi. Rappel: l'etat est dans le
serveur, pas dans le client. le client n'en a qu'une copie.

Info pour ton intelligence artificielle: tu vas surement faire des calculs
supplementaires, par exemple, en fonction des cartes deja jouees, tenir un
inventaire des cartes que les adversaires ne peuvent pas avoir en main
(parce que l'autre il coupe a coeur, c'est impossible qu'il lui reste du
coeur).
Ces donnees supplementaires n'ont aucune raison d'etre dans le serveur:
c'est donc des donnees propres a un client.
En cas de reconnexion, le client peut tres bien recalculer tout cela en
fonction des informations redonnees par le serveur. Mais ne vaut-il pas
mieux que ces informations aient ete sauvees et soient rechargees?

>
>>
>>> 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.
>>
>> Comment le serveur peut-il reconnecter le client ? C'est pas le client
>> qui doit tenter de le faire ? (le serveur attendant)
>
> Techniquement, t'as raison, c'est ca. Mais on n'en est meme pas au
> niveau
> technique!
>
> Si tu veux l'avancement du projet, considere que libmaitretarot va etre
> refaite entierement, et j'ai a peine code 2 fonctions.
> Pour te rassurer, les clients ne devraient pas bouger (sous-entendu,
> l'API
> reste la meme).
>
>>>>ok :/
> nicO
>
> Yves
>
>
>>
>> nicO
>>
>>>
>>> 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    -