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

[philippe brochard]

"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