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

[philippe brochard]

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

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.


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


> Le chat en lui-meme, c'est a mon avis la priorite la plus 
> basse: on a autre chose a faire.
> 
tout a fait d'accord, mais effectivement, il faut pouvoir en
tenir compte dans le protocole.



Philippe

-- 
,-------------------.         ,---------------,----------------------.
| Philippe Brochard |   ...   | address@hidden | http://hocwp.free.fr |
`------------------(_  (. .)  `---------------'----------------------'
-------------------ooO--(_)--Ooo--------------------------------------