Re: [Maitretarot-devel-fr] protocole

[philippe brochard]

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

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