Re: [Maitretarot-devel-fr] protocole

[Yves Mettier]

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

>
> Autre chose. J'aimerais savoir en quoi mon protocole est plus séquentiel
>  que celui-ci...

Avec ton protocole, si on ajoute une ligne dedans, il faut l'implementer
PARTOUT pour que ca marche. Si c'est implemente dans le serveur et pas
dans un client, plus rien ne marche avec ton protocole. Cela, il faut
l'eviter a tout prix.

>
> J'ai lu en diagonale le reste sinon. J'aimerais avoir un brouillon de
> votre protocole en action (un use case comme on dit dans le monde de
> l'ingéniérie logicielle :-) ) pour voir comment il se comporte. C'est
> bien joli de donner des concepts, encore faut-il les voir à l'oeuvre,
> c'est plus parlant.

Tu as deja un protocole qui marche et qui est tres lourd a etendre, celui
de l'actuel maitretarot. Pour l'instant, la seule difference entre ton
protocole et celui-la est que le tiens est texte et celui de maitretarot
est binaire. C'est une difference de forme, alors que le probleme
(protocole sequentiel donc difficile a etendre) est au niveau du fond.

La redaction, Philippe va s'en charger, et sinon, c'est moi des que j'ai
un peu plus de temps libre.

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

> et n'utilisera donc pas cette instruction). Mais comme je vous l'ai
> dit, j'aimerais voir comment vous vous en servez, car je vois pas mal
> de points potentiels à problème. (Et au fait, je pourrais *très
> facilement* rajouter cette instruction dans mon protocole _et dans son
> implémentation actuelle_, infirmant ainsi la théorie de protocole
> statique séquentiel ne pouvant supporter aucune modification).

Je suis interesse par les problemes que ca peut poser, parce qu'il vaut
mieux les envisager tout de suite plutot que de les corriger apres.

Je suis aussi tres curieux de savoir comment tu peux faire, avec un
protocole sequentiel, pour ajouter une modification sur le serveur, et que
si le client ne subit aucun changement suite a cette modification, que
l'ensemble tourne encore. C'est justement cela precisement qui nous amene
a changer le protocole (et accessoirement, on en profite pour le passer en
texte au lieu du binaire)

Yves


>
>
> Voilà,
> Jérôme
> --
> address@hidden
>
>
>
> _______________________________________________
> 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     -