Re: [Maitretarot-devel-fr] protocole

[Yves Mettier]

>
> Bon, je viens de finir une version du protocle, pour
> l'instant c'est ce qui me parrait le plus simple par
> rapport a ce qu'on a deja code.
>
> Il reste des points flous dont on a discuter avec Jerome.
> Entre autre le fait d'envoyer systematiquement toutes les
> donnees sur le reseaux ne semble pas tres pertinent (entre
> autre au moment de l'envoi des cartes).

Pareil. Mais ca, si je me souviens que le point a ete aborde plusieurs
fois, personne n'a jamais ete pour, si?
Exemple: pour l'envoi des 18 cartes, on le fait une fois et une seule,
lorsqu'elles sont distribuees. Seul le client php aura un traitement de
faveur si quelqu'un le code un jour.

> De mon point de vue, ceci permet qu'en meme de simplifier
> les clients et d'eviter le code en double (le meme code
> dans les clients et dans le serveur) et ceci evite au client
> et au serveur d'etre synchro (ce qui est tres important si on
> ne veux pas retrouver les memes difficultes qu'on a deja rencontre).
> Mais les fonctions de parser des differentes actions, ne seront
> peut etre pas forcement simples a faire.

Au niveau du parser, je m'occupe de faire une fonction qui va lire une
ligne terminee par un \n.
Une seconde renverra un tableau de chaines de caracteres, avec
tab[0]=commande, tab[1]=clef, et tab[2..n-1]=valeurs (et tab[n]=NULL
evidemment:)
Ceci est du code commun aux clients et au serveur.

Ensuite, nous verrons si l'on a besoin de couches superieures en dessous
de la couche application (au sens applicatif, pas au sens reseau du
terme).


Yves

>
> "Yves Mettier" <address@hidden> writes:
>
>> > Yves Mettier wrote:
>> >> >> Je suis partisan du ACK, mais ca donne un peu plus de boulot, et
>> je
>> >> suis pas tout a fait sur que ce soit la meilleure solution.
>> >> > Je suis aussi pour le ACK, meme si la plupart du temps
>> >> > il ne sera pas utilise.
>> >> Bah si, puisque dans ce cas, a chaque INFO recu, le client devra
>> faire un ACK
>> >
>> >
>> > Personnellement, je suis *tout à fait contre* le ACK. Vous êtes en
>> train
>> >  de vous assurer une "couche de transport" au niveau du protocole.
>> > Laissez TCP faire son boulot et ne le dupliquez pas (moins bien en
>> plus). Sans compter que ça implique de rajouter un état
>> supplémentaire pour *chaque* connexion afin de savoir si elle a reçu
>> la trame... Stoppez tout !
>>
>> Tu n'as pas compris l'interet du ACK. Le but n'est pas de faire un
>> ACK, mais de permettre au client de "prendre la parole" etant donne
>> que tout ce qu'il dit lorsqu'il n'y est pas invite n'est pas pris en
>> compte et est ignore.
>> Si on ne met pas ce ACK, cela diminue le nombre de cas ou le client
>> peut prendre la parole en cas de besoin.
>>
>> Maintenant, question: y a-t-il des cas ou le client serait susceptible
>> d'avoir besoin de prendre la parole.
>>
>> Si le fait que ce nom ACK gene pour la reflection, on peut le
>> remplacer par un NOTHING_TO_ASK, pour que les choses soient plus
>> claires.
>>
> bon, pour l'instant je ne me suis pas servi du ACK du client,
> il faudra voir par la suite si on s'en sert ou pas.
> Question : est-ce que le client a besoin de prendre la main
> sur le serveur ? (de mon point de vue : non)
>
> [...]
>
>
>> > L'idée du ASK est intéressante, car elle permet à un client de se
>> resynchroniser (bien qu'en réalité je ne suis pas sûr que ce soit
>> réellement utile, car si un client est planté, il ne s'en rendra,
>> par définition, pas compte - sauf si c'est un humain jouant en
>> telnet :o) -
>>
>> Le client n'est JAMAIS synchronise avec le serveur. Le ASK est donc
>> necessaire pour realiser cette synchronisation le temps d'une
>> transaction. Si serveur et clients doivent tout le temps etre
>> synchronises, c'est a nouveal le probleme du protocole sequentiel.
>>
> toutafait :)
>
>
> [...]
>
>
> Philippe
>
>
> --
> (    )
>  ~oo~         Philippe Brochard    <address@hidden>
>   .. Gnu!                           http://hocwp.free.fr
>   / =\   \ -   -    -   -=-= http://www.fsf.org/home.fr.html =-=-
>
>
> _______________________________________________
> 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     -