Re: [Maitretarot-devel-fr] protocole

[philippe brochard]

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

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


[...]


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


Philippe


-- 
(    )
 ~oo~         Philippe Brochard    <address@hidden>
  .. Gnu!                           http://hocwp.free.fr
  / =\   \=
 -   -    -   -=-= http://www.fsf.org/home.fr.html =-=-