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

[philippe brochard]

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

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

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 ?!?).

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

en français: le serveur est controlable par un autre prog 
(via socket), mais pas par le client.
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).


> [...]
> 
> Ci-dessous, les lignes responsables de la signature 
> incorrecte des messages. Donc inutile de signer (avec 
> gpg) les messages a la ml.
> 

ok.


Philippe