Re: Rep:Re: [Maitretarot-devel-fr] le client fonctionne :)

[address@hidden]

> "address@hidden"<address@hidden> writes:
>
> > > "address@hidden"<address@hidden>
> > writes:
> > >
> > > > > "address@hidden"<address@hidden>
> > > > writes:
> > > > >
> > > > > > En gros, c'est ca.
> > > > > > man select
> > > > > > man poll
> > > > > >
> > > > > > Moi, je suis pour select. Poll est sympa aussi
> > mais
> > > > est
> > > > > > moins portable (ca march sur solaris quand meme).
> > > > select
> > > > > > est pas posix mais est super portable. pselect
> > est
> > > > posix,
> > > > > > mais c'est pas sur solaris2.6.
> > > > > > Bref, je prefere select.
> > > > > >
> > > > > > A moins qu'on n'utilise le read non bloquand?
> > > > > >
> > > > > >
> > > > > le principe (si j'ai bien compris) de select c'est
> > de
> > > > regarder
> > > > > une entree pendant n secondes et au bout de se
> > temps de
> > > > dire
> > > > > s'il y a des donnees sur l'entree ou non.
> > > > > => ca permet de faire une boucle en attendant qu'il
> > y
> > > > ait des
> > > > > donnees et de les traiter en fonction du canal.
> > > >
> > > > Exact!
> > > >
> > > > >
> > > > > Pour poll, ca me semble un peu plus compliquer (je
> > n'y
> > > > ai pas
> > > > > trop regarde).
> > > >
> > > > Poll semble un peu plus complique, mais ca n'est pas
> > plus
> > > > complique. Simplement, faut faire le malloc du
> > tableau a
> > > > fournir en argument a poll. C'est ce malloc qui
> > semble
> > > > plus complique.
> > > >
> > > > >
> > > > >
> > > > > Donc, moi ca me va. A moins qu'il y est des
> > arguments
> > > > plus
> > > > > convainquant pour le read non bloquant.
> > > >
> > > > read non bloquant: plus simple a faire, et ca bouffe
> > pas
> > > > de memoire ni de cpu. Bref, mieux: on a besoin d'une
> > > > seule ligne de code pour ca.
> > > >
> > > > A mon avis, faut voir le besoin reel, et coder en
> > > > fonction quand on en aura besoin.
> > > >
> > > Ok, enfin pour l'instant ce qui serai bien c'est qu'on
> > fasse
> > > une partie complete (blindage su serveur, fin du client)
> > > Et on pourra voir ce qu'on fait apres (IA, chat...)
> > >
> > > D'ailleurs, le chat on peut le mettre dans la version 2
> > plutot
> > > que dans la 1 non ?
> >
> > Non, enfin pas tout a fait.
> > Le protocole doit etre pret pour le chat, meme si le chat
> > lui-meme n'est pas implemente. Sinon, on va se retrouver
> > avec des versions incompatibles de maitretarot et de
> > clients!
> >
> bon, et bien alors on peut modifier le protocle en disant
> que, chaque fois qu'on envoie un ou une serie de gint, avant
> on rajoute un gint (le canal) pour savoir a qui s'adresse
> les gint (jeu ou chat).

Oui.

>
> Puis on modifie les fonctions read_data/write_data pour
quelles
> lisent/envoient un gint (le canal) avant de lire/envoyer
la serie
> de gint (le jeu).
> Ces nouvelles fonctions read_data et write_data peuvent etre
> des intermediaires:
> On peut avoir un truc du style:
>
> read/write => lit/ecrit des gint
>                 (tres general: read_data/write_data actuel)
>
> read_data/write_data => read/write ([canal+data],
size(canal+data))
>
> utilisation_des_donnes => canal=-1: pas de donnee
>                           canal=0: le jeu -> data=les
cartes, le chien...
>                           canal=1: le chat -> data=la
chaine du chat
>
>
> le fonctions read/write corresponde aux fonctions read_data
> et write_data actuelles mais en non bloquantes.
>
> l'utilisation des donnees (pour la lecture) fait une boucle
> tant que canal=-1 (pas de donnes), affiche le chat quand
> canal=1 ou sort quand canal=0 (le jeu) et traite les datas
> comme le protocole actuel.

Deja, on ne touche pas a read_data et write_data.
On fait d'autres fonctions. Ca revient a ce que tu disais,
sauf qu'il faudra trouver d'autres noms. C'est juste de la
semantique.
read_data et write_data seront donc nos fonctions de plus
bas niveau. Il faudra juste les modifier pour les sockets
non bloquantes: verifier que ca ne plante pas.

Ensuite, je suis d'avis qu'on fasse nos trucs dans nos
coin, tout en nous concertant. Ainsi, on aura des
fonctions qui correspondent a nos besoins. Et un jour (le
plus tot possible quand meme), on met les trucs communs
dans libmaitretarot. Exactement ce qu'on a fait avec
read_data.

>
>
> voila, je crois que c'est une solution possible.

Oui.

De mon cote, j'ai un week-end a rien faire (juste passer
chez le coiffeur et faire les courses).

Vu le temps, je pense que je vais faire 50% de
maitretarot, 50% a me faire une distrib sur disquette
(c'est mon nouveau data) et 50% a rien faire. Plus 50% a
mater l'un ou l'autre dvd.
Donc des qu'il y a de l'activite sur la ml de maitretarot,
je fais du maitretarot.

Au fait, on n'a plus de nouvelles de Guillaume?

Yves
--
homepage - http://ymettier.free.fr                   -
gtktalog - http://www.freesoftware.fsf.org/gtktalog  -
cardpics - http://www.freesoftware.fsf.org/cardpics/ -

--------------
Profitez des 2 offres exceptionnelles Tiscali !
"Internet Gratuit le Jour" et "Modem ADSL remboursé"
Cliquez ici, http://register.tiscali.fr/forfaits_ls/
Offres soumises à conditions.