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

[Yves Mettier]

On 11 Mar 2002 17:54:31 +0100
philippe brochard <address@hidden> wrote:

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

C'est mieux. C'est plus logique.
Et dans la version 2.72.11, on pourra aussi mettre un mode ou on ne
donne que l'etat actuel du jeu d'un joueur, comme quand quelqu'un vient
regarder le jeu d'un autre en cours de partie.;-)

> 
> > 
> > > 
> > > 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 :)

'rci :)

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

Ca, c'est le protocole de connexion. C'est a Guillaume de bosser dessus!
Et du coup, ca ressouleve le probleme de l'interface utilisateur sur le
serveur: comment dit-on dynamiquement au serveur que la partie peut
commencer? Y'a plein de solutions.- le serveur envoie a tous les clients
le nombre de connectes a chaque nouveau connecte. Et un client peut dire
au serveur "on est N, c'est bon, on peut commencer".- configuration dans
le fichier de conf. Du coup, il faut faire un prog qui aille ecrire dans
le fichier de conf. Peut-etre qu'il en faudra de toute facon un par la
suite?- le premier client indique le nombre de joueurs a attendre. Des
que tout le monde est la, la partie commence.

C'est non exhaustif. Je crois que les 3 possibilites sont toutes aussi
proches de la realite les unes que les autres. La troisieme est un peu
dictatoriale: j'aime moins.

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

if(write_data(donnees) != sizeof(donnees)) {
  tu fais quoi dans ce cas?
}

A mon avis, si ce cas arrive, faut avoir une fonction a appeler. Cette
fonction doit etre capable d'attendre une reconnexion d'un client, tout
en testant les autres connexions. Si les autres tombent aussi, alors
c'est la fin du jeu.

Quel est le protocole quand on a au moins une IA pour deconnecter l'IA
via une interface utilisateur? Je veux bien un kill au depart. Mais les
utilisateurs de mac, ils aiment pas la ligne de commande.

Yves
-- 
- Homepage - http://ymettier.free.fr                   -
- GPG key  - http://ymettier.free.fr/gpg.txt           -
- MyAM     - http://www.freesoftware.fsf.org/myam      -
- GTKtalog - http://www.freesoftware.fsf.org/gtktalog  -