Re: [Maitretarot-devel-fr] protocole

[philippe brochard]

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

[...]


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

> >
> >>
> >> Autre remarque: le chat. A mon avis, alors que tout le reste est
> >> synchrone (le client ne parle que si le serveur a fait une demande),
> >> le chat est asynchrone. On peut le faire passer via une commande CHAT.
> >> Cela devrait un poil compliquer les clients qui veulent gerer cette
> >> fonctionnalite future. Cela devrait beaucoup compliquer le serveur qui
> >> du coup doit ecouter sur ses sockets a tout moment. Je suis assez pour
> >> implementer un support possible de cette fonctionnalite, car si on ne
> >> prevoit pas cette fonctionnalite a l'avance, il faudra recoder le
> >> serveur quasi en entier si on veut implementer une fonctionnalite
> >> asynchrone, quelle qu'elle soit. Mais est-ce vraiment la peine pour le
> >> chat?
> >> Il y a irc, icu et d'autres protocoles pour discuter en meme temps. Un
> >> tel protocole rajoute peut-etre des problemes de securite (quoiqu'a
> >> premiere vue je n'en vois pas). Bref, on verra ca plus tard. Ne nous
> >> fermons pas les portes :)
> >>
> > La commande CHAT (ou une autre) est peut etre interressante
> > si on doit communiquer de maniere asynchrone, mais je me
> > demande si ca ne complique pas enormement les choses, alors
> > qu'il suffirai d'ouvrir un autre port pour faire du chat
> > ou des communication asynchrone.
> 
> On va pas quand meme utiliser 2 sockets!?
> 
> > Est-ce vraiment handicapant si on ouvre 2 sockets (exemple port
> > 2551 et 2552) l'une pour le protocole, l'autre pour les
> > communications asynchrone ?
> 
> Non, mais dans ce cas, je fais aussi un malloc des 3/4 de la memoire vive,
> comme ca, je suis sur d'avoir assez de memoire tout le temps.
> 
arf, oui pas bete !
On alloue la moitie de la memoire et ensuite on peut
faire des acces memoire au hasard !
chouette, on va enfin pouvoir ce passer des malloc :) 

Bon, donc c'est handicapant...
Donc on se debrouille pour avoir qu'une seule socket et
on voit plus tard pour le chat.

> >
> >
> > Des que j'ai le temps, je redige le protocole en partant
> > des fonctions et en me bassant sur les trois actions
> > S->C : ASK, C->S : SAY et S->C : INFO.
> 
> OK.
> 
> Faudra aussi clairement remarquer que:
> INFO n'implique jamais de reponse de la part du client

sauf si le client a besoin de faire un ACK pour
demander quelque chose au serveur.

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



Philippe

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