Re: [Maitretarot-devel-fr] protocole

[Yves Mettier]

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

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

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

Oui

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

Oui

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

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     -