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:
> > > > 
> > > > > > "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.
> 
tout a fait, je n'avai pas trop d'inspiration pour les
fonctions (read et write c'est deja pris, mais ca montre
le bas niveau). un truc du genre: read_data/write_data,
read_canal_data/write_canal_data ca va ? (ou chanel pour
la convention anglaise). 

> > 
> > 
> > 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.
> 
Ouais, moi j'ai des paquets de copies a corriger (pt1 de
devoir commun), mais sinon je pense que je trouverai le
temps de finir le client (faire une partie complete).

Ensuite j'aimerai bien mettre en place la partie commune
pour la communication client/serveur et faire l'IA de
base (qui dependra de la partie commune).
Ensuite passer a glib-2.0, faire le chat...
(ca ressemble a un TODO ca !)


> Au fait, on n'a plus de nouvelles de Guillaume?
> 
oui, c'est vrai ca, Guillaume t'es OU ???



Philippe

-- 
philippe brochard <address@hidden>
                  http://hocwp.free.fr