maitretarot-devel-fr
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: philippe brochard
Subject: Re: Rep:Re: [Maitretarot-devel-fr] le client fonctionne :)
Date: 24 May 2002 18:26:38 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

"address@hidden"<address@hidden> writes:

> > "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). 
> > 
> 
> chanel_read_data?
> 
ca me va :)

> Bah on va prendre un truc comme ca. De toute facon, apres,
> y'a encore le prototype a decider.
> Cree ta fonction comme bon te semble.
> Je ferai la mienne. Et bien evidemment, autorisation de se
> pomper l'un l'autre!
>
Evidemeeeeeennnnnttttt !!! parce que c'est le meilleur moyen
de faire un truc fonctionnel.

> Et quand on aura un truc qui marche, on regardera nos
> prototypes et on en prendra un bien. Pense juste a
> utiliser GError pour la gestion des erreurs si l'erreur ne
> se limite pas a "ca a marche/ca n'a pas marche".
> 
Ok pour les GError (RTFM pour moi :) 

> > > > 
> > > > 
> > > > 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 !)
> 
> Oui.
> Bah moi, je verrai ma motivation. Peut-etre que je ferai
> un fork de maitretarot pour ajouter le gint et changer le
> protcole comme on a dit. Et aussi ajouter les encheres.
> Ce sera un fork, donc je ne ferai pas de commit sur le cvs
> actuel. Au pire, je creerai une nouvelle branche.
> 
oui, s'il te plait, ne modifie pas la branche principale
de maitretarot, du moins pas avant que le client ne soit
pleinement fonctionnel au niveau du protocole du jeu.
(j'ai encore des tests a faire).

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


Philippe

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]