Re: [Maitretarot-devel-fr] protocole

[Jerome Quelin]

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 !

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

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.

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


Voilà,
Jérôme
-- 
address@hidden