[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Maitretarot-devel-fr] Re: [Maitretarot-devel-fr] port par défaut
From: |
philippe brochard |
Subject: |
Re: [Maitretarot-devel-fr] Re: [Maitretarot-devel-fr] port par défaut. |
Date: |
11 Mar 2002 17:54:31 +0100 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 |
"address@hidden"<address@hidden> writes:
> > "address@hidden"<address@hidden>
> writes:
> >
> > > > "address@hidden"<address@hidden>
> > > writes:
> > > >
> > > > > > le lun 11-03-2002 Ã 09:04,
> address@hidden
> > > a
> > > > > écrit :
> > > > >
> > > > > > > J'ai pense a un truc hier aussi: le serveur
> doit
> > > > > aussi
> > > > > > > avoir une interface d'ecoute (un port, quoi)
> > > reserve
> > > > > a
> > > > > > > une interface utilsateur. Ceci afin de
> pouvoir
> > > > > controler
> > > > > > > le serveur facilement.
> > > > > > > - quitter quand on veut
> > > > > > > - configurer via une GUI et pas via un
> fichier
> > > texte
> > > > > avec
> > > > > > > vi/emacs.
> > > > > > > - afficher les scores
> > > > > > > - autres idees?
> > > > > > ce port peut aussi servir au chat. Il utilise
> des
> > > > > commandes à la irc
> > > > > > /score -> donne les scores etc...
> > > > > > pas de commande envoie le message aux autres
> > > joueurs.
> > > > > >
> > > > > > >
> > > > > > > Je sais pas si c'est une excellente idee car
> on
> > > peut
> > > > > > > aussi donner cette interface de controle aux
> > > clients:
> > > > > le
> > > > > > > serveur peut envoyer les scores a chaque
> client a
> > > la
> > > > > fin.
> > > > > > Je pense qu'il doit le faire aussi (envoyer les
> > > score Ã
> > > > > la fin). Il faut
> > > > > > les deux.
> > > > > > Le premier client connecté à le role de maitre
> du
> > > > > serveur (un peu comme
> > > > > > avec tetrinet). c'est le seul à pouvoir envoyer
> des
> > > > > commande au serveur.
> > > > > > une commande spéciale lui permet de donner ces
> > > droit Ã
> > > > > un autre
> > > > > > utilisateur. l'interface du client peut
> disposer de
> > > > > facilité pour
> > > > > > exécuter ces commandes, mais on doit pouvoir
> les
> > > > > réaliser en mode texte.
> > > > >
> > > > > Pourquoi seul le premier client aurait le droit
> > > d'envoyer
> > > > > des commandes au serveur? Je crois que ca
> complique!
> > > > > Faudrait recenser les ordres a donner au serveur.
> > > Pour
> > > > > l'instant, je ne vois que:
> > > > > - deconnexion d'un client
> > > > > - demande des scores
> > > > >
> > > >
> > > > est-ce que c'est vraiment la peine que le client
> envoye
> > > des
> > > > commandes au serveur.
> > > >
> > > > - deconnexion d'un client : que ce passe-t-il si un
> > > client
> > > > quitte le jeu sans rien dire (ex: un crache). Il
> ne
> > > faut
> > > > pas que ça plante le serveur.
> > > > C'est peut être au serveur de retester si le
> client
> > > est
> > > > toujours là avant de continuer (ex: test avant
> > > d'envoyer
> > > > les cartes, test avant d'envoyer les scores...).
> > >
> > > Exact.
> > > Question subsidiaire pour savoir si ton argument
> suffit
> > > ou s'il faut continuer a discuter: si un joueur va
> dans
> > > le menu et clique sur quitter. S'il y a juste
> > > deconnexion, que se passe-t-il sur le serveur; que se
> > > passe-t-il sur les autres clients?
> > >
> >
> > le serveur dit aux autres clients qu'un client vient de
> > qitter la partie.
>
> Oui.
>
> > Deux choix, soit on arrete la partie, soit le serveur
> > attend un nouveau client (humain ou IA) qui reprend le
> > jeu de celui qui a quitter.
>
> Oui. J'ai failli dire non: vaut mieux tout quitter et
> recommencer, mais si c'est une deconnexion accidentelle,
> il suffit de reconnecter, et cela correspond a ce que tu
> viens de dire. Cela implique que le serveur informe le
> client de l'etat de la partie.
>
> >
> > > >
> > > > - demande des scores : les scores ne changent pas
> au
> > > cours de
> > > > la partie. Donc un envoie des scores par le
> serveur Ã
> > > la
> > > > fin de la partie devrait suffir.
> > > > Sinon, pour le nombre de plis joués, le nombre de
> > > cartes en
> > > > main, c'est au client de suivre le jeu ou alors
> le
> > > serveur
> > > > lui renvoie ces valeurs à un moment donné dans le
> > > protocole,
> > > > mais je ne crois pas que ce soit au client de les
> > > reclamer.
> > >
> > > Sur ce point, je suis d'accord.
> > > Mon argument vient d'une idee qu'il faudrait
> implementer
> > > dans la version 3.19.12 (le mode corruption, c'est
> dans
> > > la 4.12 si je me souviens bien), c'est de pouvoir
> > > rajouter n (n quelconque) clients pour regarder la
> > > partie. C'est plus facile de les brancher au debut,
> mais
> > > au milieu, c'est aussi eventuellement interessant.
> > > D'autre part, un tel client peut servir d'interface
> de
> > > debogage pratique: on demande le jeu d'un client (une
> IA
> > > par exemple) et on regarde comment elle joue.
> > >
> >
> > donc dans ce cas, ça serai pas mal qu'a chaque pli le
> > serveur envoi aux clients les cartes qu'ils ont en
> > mains et dans le chien.
>
> Bof.
ouais, je sais c'est pas optimal. mais alors, il faut
que le serveur envoi le jeu et le chien à un nouveau
client/spectateur quand il se connecte.
>
> >
> > si qq1 veut regarder la partie, il dit qu'il regarde le
> > jeu de tel client et voit sont jeux (euh, ça peut pas
> > poser des pb de triche ça ?!?).
>
> Oui.
> Et dans la realite, c'est pareil. Mais dans la realite,
> on peut aussi interdire a qq de regarder, en cachant
> mieux son jeu. De la meme maniere, un client peut
> interdire le serveur de montrer son jeu a d'autres. C'est
> une fonctionnalite a implementer par la suite.
>
ok, vu comme ça, ça marche.
> >
> > > > Sinon, une GUI integrée au serveur pour que celui
> qui
> > > l'a
> > > > lancé le controle, ça ne suffit pas (en plus du
> fichier
> > > de
> > > > conf et de la ligne de commande) ?
> > >
> > > Si je puis me permettre: interdiction de mettre une
> GUI
> > > dans le serveur. Le serveur doit pouvoir tourner sur
> un
> > > environnement non graphique, ou un environnement
> > > graphique ne disposant que de certaines libs et pas
> > > d'autres. Donc si on veut une GUI au serveur, il faut
> que
> > > ce soit comme les clients, on la connecte au serveur
> (via
> > > socket, c'est le plus facile). Et c'est en
> reflechissant
> > > a ca que je me suis dit qu'un client capable de
> donner
> > > des ordre suffirait. Mais a-t-on vraiment besoin d'un
> > > client capable de donner des ordres?
> > >
> >
> > ben, je ne suis pas sur (moi je suis pour limiter au max
> > le role du client). un truc dans ce genre serai peut
> être
> > pas mal :
> >
> > |--- client
> > GUI |--- client
> > conf <---> serveur <-->|--- client
> > ligne de commande |--- client
> > |---
> spectateur
> > ...
>
> C'etait mon idee.
>
je te la rend :)
> >
> > en français: le serveur est controlable par un autre
> prog
> > (via socket), mais pas par le client.
>
> Cependant, vu ce qui est code dans le client, il est
> capable d'etre spectateur. C'est au serveur de ne pas
> demander son avis a un tel client.
> Donc pour m'exprimer autrement, 100% d'accord avec ton
> schema. Mais ca n'empeche pas de pouvoir avoir le meme
> code a peu de choses pres dans un client et un spectateur.
>
tout à fait, suivant le nombre de participants :
<= 4 : le client peut jouer (si il veut)
> 4 : le client est spectateur.
> > Je pense qu'il ne faut vraiment pas faire confiance au
> client,
> > donc dans ce cas, il ne doit pas etre capable de
> controler le
> > serveur (sinon -> triche possible).
>
> Seul un joueur peut avoir une action sur le serveur.
> Est-ce que la liste des actions suivantes est exhaustive?
> - jouer une carte, mais a la demande du serveur uniquement
> - indiquer une enchere, mais a la demande du serveur
> uniquement
> - indiquer de quoi on se defausse, mais a la demande du
> serveur uniquement
je crois que c'est comme ça dans le protocole.
> - fermer la socket, a tout moment, de maniere
> completement asynchrone.
>
ok, mais il faudra peut être que le serveur verifie que
le client est tjrs là en cas où il se serai deconnecté
sans prevenir.
Philippe