Re: [Maitretarot-devel-fr] protocole

[Yves Mettier]

> "Yves Mettier" <address@hidden> writes:
>
>> > "Yves Mettier" <address@hidden> writes:
>> >
>> >> Bon, y'a philippe qui a fait n'importe quoi: j'ai recu ce courrier
>> en perso donc la ml l'a pas eu.
>> >> Je reponds quand meme, en ne supprimant rien.
>> >>
>> > euh, desole...
>> >
>> > par contre, pour ce message, j'ai :
>> > Reply-To: address@hidden, address@hidden
>> >
>> > donc a priorie, tu aurai du le recevoir en double ('fin j'ai
>> > corrige pour ne renvoyer qu'a la ml).
>>
>> OK. De mon cote, la, je viens de cliquer sur le bouton "reply to ml"
>> au lieu de "reply", qui avait visiblement le meme effet, mais qui a
>> peut-etre par derriere l'effet de ne pas mettre mon email en Reply-to.
>> Les problemes viennent peut-etre de la? Mon client mail trop puissant
>> et le tien pas assez?
>>
> ben que mon client mail soit trop ou pas assez puissant, la
> j'ai encore un
> Reply-To: address@hidden, address@hidden donc

Etrange. 2 boutons differents qui font la meme chose chez moi? Arf, possible.

> si je fais pas gaffe, il va replyer :) au deux addresses
> indiquees et ca tombe bien, c'est ce que je lui demande.

:)

>
>> >
>> > [...]
>> >
>> >
>> >> >> Question: doit-on implementer une commande ACK, reponse du
>> client
>> >> au serveur lorsque le serveur envoie une commande INFO?
>> >> >> Avantage: ca permet au client d'en profiter pour demander autre
>> >> chose s'il en a besoin, puisque le client n'a le droit de parole
>> qu'en reponse a une demande du serveur. Mais est-ce necessaire?
>> >> >> Inconvenient: Ca nous rajoute du trafic reseau quasi inutile.
>> Quasi
>> >> inutile ou vraiment inutile? Meme si c'est inutile, vu que
>> >> >> l'application n'est pas specialement gourmande en bande
>> passante,
>> >> doit-on economiser ici?
>> >> >>
>> >> > Ben je ne sais pas si ca sert a grand chose.
>> >> > Quand le serveur fais un INFO puis un ASK, on devrai avoir
>> >> > prevu tout ce qu'a besoin le client dans le INFO.
>> >> > Ca va compliquer les choses si le client peut/doit demander des
>> choses non prevues.
>> >>
>> >> Ca peut compliquer du cote serveur. Du cote client, non, au
>> contraire. Mais ca, c'est a la fois une fonctionnalite ET une
>> resistance au erreurs de protocole. Donc faut l'implementer, meme
>> si le client ne s'en sert pas.
>> >>
>> > Ok, donc on rajoute la sequence :
>> >
>> > S->C : INFO ... ; C->S : ACK ...
>> >
>> > et seulement dans le cas d'un INFO venant du serveur.
>>
>> Cela implique une gestion d'erreur...
>> Que doit faire le serveur s'il ne recoit pas de ACK?
>> Hors de question de continuer comme si de rien n'etait dans ce cas:
>> soit le client a un probleme, soit le client est de mauvaise volonte,
>> mais dans les deux cas, faut le balancer.
>> Alors que si on n'implemente pas le ACK, le serveur, il peut envoyer
>> ses INFO tant que c'est lu en face sans se preoccuper que le client a
>> bien recu ca.
>>
>> 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

>
> Par contre, est-ce que ca complique beaucoup les choses
> si on fait en sorte de prendre en compte un ACK si le
> client en fait un, et continuer s'il ni y a pas de ACK.
> C'est a dire que le ACK n'interviendrai qu'au moment d'un
> INFO du serveur et que s'il y en a vraiment besoin (et non
> pas a chaque INFO) ?

Oui, ca complique parce que ca detruit completement la synchro. Et du
coup, ca detruit l'utilite du ACK. Dans ce cas, il ne sert a rien du tout.

> Boh, ca complique peut etre un peu trop les choses,
> je pense qu'en meme qu'il vaut mieux envoyer le ACK a chaque
> fois et gerer l'erreur s'il n'est pas present.
> Ou alors ne pas le mettre, mais ca veux dire que le client
> ne peut plus faire de demande au serveur (ce qui n'est
> peut etre pas plus mal).

Oui, toujours ou jamais, mais pas fonction de la vitesse du vent ou du
cours de la bourse.

Bref, si personne d'autre n'intervient avec un argument interessant, je te
laisse choisir: ACK ou pas ACK

>
>
> [...]
>
>
>> >> ASK implique toujours une reponse de la part du client si c'est le
>> serveur qui l'envoie. Si c'est le client, le serveur est prie de
>> repondre. SAY est une reponse a ASK
>> >>
>> > ok
>> >
>> >> Il faut une commande pour dire "I don't know". DUNNO ?
>> >>
>> > ca me va.
>>
>> Let's go.
>>
>> Donc les commandes sont:
>> * INFO (serveur uniquement)
>> * ACK (client uniquement puisque c'est une reponse a INFO du serveur)
>>
>> * ASK (client ou serveur)
>> * SAY (client ou serveur, reponse au ASK de l'autre)
>>
>> * DUNNO (reponse a n'importe quelle commande, signifiant que ce n'est
>> pas encore implemente. C'est un ACK en quelques sortes, mais
>> signifiant que ce n'est pas implemente et qu'il faut pas s'attendre a
>> une meilleure reponse)
>>
>> Y a-t-il d'autres commandes?
>>
> Je pense qu'avec ca on fait le tour.
>
> Par contre, dans les cas sans erreurs, je pense que le
> ASK client et le SAY serveur seront inutilises (parce
> que ca veux dire que lorsque le client fait un ASK, il demande
> quelque chose au serveur, alors que ce serai bien que le
> client soit la plupart du temps passif et que ce soit
> le serveur qui engage les conversations).

Oui. Un ASK du client (et un SAY du serveur) ne devrait en theorie, et au
vu de ce que nous faisons, jamais arriver.

Yves

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