[Maitretarot-devel-fr] Re: [Maitretarot-devel-fr] port par défaut .

[address@hidden]

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

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

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

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

> 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
- fermer la socket, a tout moment, de maniere
completement asynchrone.

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

--------------
Profitez de l'offre spéciale Tiscali Liberty Surf !
50% de temps en plus pendant 3 mois sur tous les forfaits Internet.

http://register.libertysurf.fr/subscribe_fr/signup.php3