Discussion :

[regma]

Discussion déplacée, elle commence au dernier message de ce sujet, içi même

Bonjour,

Je viens de débuter sur pthread et je réfléchis à comment organiser mon code mais je bloque sur certains points :

Contexte :
J'ai 2 clients qui s'adresse au serveur par une requête http://URL
Je passe à cette requête un identifiant_client.
Le MasterThread ouvre un thread différent pour chaque client.
Ces 2 thread(thread 1 et thread 2) communiquent entre eux dans le cadre de traitements pour une cause commune.



Problèmes :
- Lorsqu'un des thread est en attente d'une information qu'un client doit transmettre, comment le serveur saura que l'information doit être traitée par le thread 1 et pas par le thread 2 ?

Autrement dit, comment spécifier dans la requête, j'envoie cette information pour le thread 1 qui est en attente ?

-Qui doit s'occuper de la redirection vers le bon thread ? est ce le travail du MasterThread ou faut il faire autrement ?

Merci d'avance pour vos réponses

[Matt_Houston]

Tu abordes deux aspects bien distincts de ton projet :

• le protocole de communication client-serveur ;
• le traitement réalisé sur le serveur (dont tu souhaiterais l'implémentation potentiellement multithreadée).

Tu nous dis plus de choses sur la nature du premier que sur celle du second.

Le sage principe de responsabilité unique nous indique que le client n'a absolument pas à savoir ce qui se passe en interne sur le serveur. Les processus clients n'ont pas à « communiquer avec les threads » du serveur. Ils voient le serveur comme un unique host, une boîte noire. La manière dont il réalise son travail n'est pas de leur ressort.

Maintenant, techniquement, il est possible de faire en sorte que chaque thread du serveur écoute le descripteur auquel il est associé à l'établissement de la connexion. Pour plusieurs raisons c'est en général une mauvaise conception. Un choix d'implémentation des plus classiques d'un serveur multi-clients repose au contraire sur l'appel système select, qui permet d'écouter plusieurs descripteurs. Selon le besoin les traitements peuvent toujours être ensuite dispatchés sur différents threads.

[regma]

mercii de m'avoir répondu.

Tu nous dis plus de choses sur la nature du premier que sur celle du second.

En fait j'ai fais quelques posts et je n'ai pas eu tellement de réponse, du coup je ne voulais pas partir sur un pavé.
Voici le lien vers le post originel où j'ai vraiment exposé les traitements à faire, post qui m'a amené à me tourner vers pthread.
Mais je n'ai pas tout dit sur cet utilisation de pthread, en fait j'ai installé cette implémentation de Pthread en PHP sur mon serveur web.

le client n'a absolument pas à savoir ce qui se passe en interne sur le serveur

J'ai vraiment du mal à saisir dans ce cas comment le client peut contrôler à quels points de traitements en est le thread du serveur ? par exemple quand doit il transmettre les informations pour que le thread passe au traitement suivant.

Un choix d'implémentation des plus classiques d'un serveur multi-clients repose au contraire sur l'appel système select, qui permet d'écouter plusieurs descripteurs. Selon le besoin les traitements peuvent toujours être ensuite dispatchés sur différents threads.

Donc si je le redis à ma manière(peux tu le confirmer stp ?), c'est l'appel système select qui me permettra de "pointer" sur tel thread pour continuer un traitement ?


-Je compte suivre tes directives et tes conseils. c'est pourquoi j'aimerai en savoir plus sur cet appel système select, mais comme je le devines ce doit être un appel système Linux, et je suis sur mon serveur web en local sous Wndows


merci encore.

[Matt_Houston]

Pour le moment je ne vois rien qui nécessite plus d'un thread. Introduire des threads supplémentaires au sein d'un programme en complexifie grandement l'exécution et doit se justifier point par point. Ce que tu cherches à faire est un jeu à deux joueurs ; possiblement distants certes, mais ça n'a pas l'air de requérir une immense quantité de ressources. Commence modeste et il sera toujours temps de pallier les hypothétiques problèmes de performance plus tard.

Je vois également beaucoup de choix techniques : PHP, HTTP, C, pthreads.. mais pas de détails concrets sur ce que tu cherches à réaliser. Comment es-tu parvenu à déterminer que ces solutions sont pertinentes pour ton application ?

J'ai vraiment du mal à saisir dans ce cas comment le client peut contrôler à quels points de traitements en est le thread du serveur ? par exemple quand doit il transmettre les informations pour que le thread passe au traitement suivant.
[...]
Donc si je le redis à ma manière(peux tu le confirmer stp ?), c'est l'appel système select qui me permettra de "pointer" sur tel thread pour continuer un traitement ?

Tu n'y es pas : le client et le serveur se mettent d'accord pour établir un canal de communication privilégié, puis s'en servent pour s'échanger des messages uniquement. Il revient à chacun d'interpréter leur contenu. Le client envoie des commandes, comme je veux me déplacer vers la gauche ; à réception le serveur juge si cette commande est pertinente ou pas selon l'état courant du jeu.

Le serveur maintient donc autant de canaux que de clients connectés. Ces canaux sont représentés par des descripteurs (sockets). select lui permet d'écouter tous ces descripteurs à la fois et de jongler entre tous les messages qui lui parviennent de sources multiples.


Il existe un équivalent à select(2) sous Windows. Cela dit méfie-toi tout de même des subtiles différences de comportement des appels système réseau bas niveau selon les plateformes. Et puis tu peux toujours utiliser une machine virtuelle sous Linux ou un Raspberry Pi pour ton serveur local..


Pour en savoir plus sur la programmation réseau en général, consulte les tutoriaux de Bousk dans la section jeux. Je crois que c'est écrit en C++ mais les concepts sont les mêmes.

[vertebre]

PS: Nous sommes 2 sur le projet, c'est pourquoi je me permet de répondre pour Regma comme nous réfléchissons à 2 et que nous n'avons pas les mêmes horaires

---

Pour le moment je ne vois rien qui nécessite plus d'un thread.

Merci pour cette analyse, je vais revoir la réflexion de mon programme.

Je vois également beaucoup de choix techniques : PHP, HTTP, C, pthreads.. mais pas de détails concrets sur ce que tu cherches à réaliser. Comment es-tu parvenu à déterminer que ces solutions sont pertinentes pour ton application ?

J'ai déterminer :

• l'utilisation du PHP par moi-même car dans mon application je fais déjà appel à des web services en PHP et je ne souhaite pas remettre en place un autre serveur, d'autre part comme tu l'as mentionné le programme ne requiert pas beaucoup de ressources c'est pourquoi je me suis tourné vers php même si les threads en PHP(en théorie) ne sont pas les plus performants. Pour compléter je n'ai pas l'envie d'échanger ma partie serveur actuelle avec un backend C ou C++.
  
• l'utilisation du HTTP(S) pour à peu près les mêmes raisons, mon application communique avec mon serveur de cette façon et je n'avais pas vraiment envie de partir sur un autre protocole de communication ou de l'implémenter dans un autre langage.
  
• Le C justement je ne suis pas à l'aise avec, mais pthreads que j'utilise en PHP provient avant tout du C. Comme mon post concerne avant tout une techno de ce langage, pour trouver une personne compétente en la matière(cf toi) je me suis résigné à poster dans ce forum.
  
• l'utilisation de pthread car après plusieurs recherches j'ai constaté que le PHP ne permettait pas de lancer des threads en parallèle, mais qu'avec pthread oui. Bien que, comme tu l'as souligné, je puisse faire mon programme dans un seul thread.
• De plus, le fait de créer 2 threads par client par l'intermédiaire d'un MasterThread m'a été conseillé par un enseignant dans le cadre de mes études mais je suis content d'avoir des avis différents et des réponses précises
  
• Je pensais également avoir besoin d'un MasterThread pour pouvoir gérer les paires de connexion client, et ainsi rediriger les connexions vers tel ou tels thread qui ont été démarrées pour ce client.
  
• Mon application n'a besoin que de cette partie serveur pour être opérationnelle, après je compte la mettre en production et je ne voudrai pas me lancer dans de nouvelles technos d'autre langage pour ce genre de traitements.
  De plus, une fois l'application publiée je vais devoir configurer mon propre serveur chez un hébergeur, configuration que je souhaite maitrisée tant dans sa mise en place que dans sa maintenance et son évolutivité.

Pourrai tu me donner un exemple de détails concrets que je devrais avoir énoncer ? je suis un peu dur de la feuille et je ne comprend pas vraiment ce que tu attends ... je pensais les avoir précisés.

Tu n'y es pas : le client et le serveur se mettent d'accord pour établir un canal de communication privilégié, puis s'en servent pour s'échanger des messages uniquement. Il revient à chacun d'interpréter leur contenu.

Donc je n'ai pas à me soucier de gérer les événements types "confirmation de réception", "confirmation d'attente", etc... ? événements que je voulais mettre en place pour synchroniser le déroulement du programme au niveau client et serveur.
Si c'est le cas, j'ai un manque d'expérience et de connaissance certains, mais j'ai également été mal conseillé sur cette façon de faire.

Le serveur maintient donc autant de canaux que de clients connectés. Ces canaux sont représentés par des descripteurs (sockets). select lui permet d'écouter tous ces descripteurs à la fois et de jongler entre tous les messages qui lui parviennent de sources multiples.

Peux tu me confirmer stp qu'il est possible de gérer ces descripteurs de fichiers(avec select) sur un Linux fourni par un hébergeur ?

Il existe un équivalent à select(2) sous Windows. Cela dit méfie-toi tout de même des subtiles différences de comportement des appels système réseau bas niveau selon les plateformes.
Et puis tu peux toujours utiliser une machine virtuelle sous Linux ou un Raspberry Pi pour ton serveur local..

Si je comprend bien, ce que j'en retire implicitement, c'est que gérer les threads avec mes requêtes sur des .php, mes petits appels http tous çà c'est mort il faut que parte sur une communication TCP et un backend en C ou C++ obligatoirement ?
Je m'en vais faire des recherches de mon coté bien sur, mais n'aurai tu pas une solution pour allier apache et un équivalent select ? tu me l'as déjà dit select est un appel système au niveau de l'OS mais je ne voudrais pas dépendre de l'OS pour gérer çà mais plutôt dépendre de mon serveur web.

Pour en savoir plus sur la programmation réseau en général, consulte les tutoriaux de Bousk dans la section jeux. Je crois que c'est écrit en C++ mais les concepts sont les mêmes.

Je n'y manquerai pas.

J'en ai appris plus dans cette discussion que durant les derniers mois passés, tu es merveilleux


bien à toi,

[Matt_Houston]

En vérité votre sujet est d'ordre général et aurait plus sa place sur le forum jeux.

Vous nous avez demandé des précisions sur la mise en œuvre de certains choix de conception sans présenter le projet depuis ses fondements. Au fur et à mesure de la discussion, nous en arrivons tous les trois à penser qu'il faut remettre en question, au moins en partie, ces choix. C'est la raison pour laquelle il faut remonter d'un cran dans la conception et nous apporter des informations plus générales.

Pourrai tu me donner un exemple de détails concrets que je devrais avoir énoncer ? je suis un peu dur de la feuille et je ne comprend pas vraiment ce que tu attends ... je pensais les avoir précisés.

Décrivez plus en détail votre jeu : le genre, les règles, la présentation graphique ; citez des jeux similaires.. Combien y'a-t-il de joueurs dans une partie : juste deux, ou s'agissait-il d'un exemple pour illustrer le problème ? À quoi ressemblent les interactions entre joueurs ? Quelle est leur fréquence : est-ce nerveux comme un FPS en deathmatch, ou posé comme une partie d'échecs ? Combien de parties un serveur peut-il héberger ? À quelle fréquence le serveur et ses clients sont-ils supposés communiquer ? Quel est l'ordre de grandeur du volume de données qui doit transiter par le réseau ? Sur quelle type de système (machine et OS) le client devra-t-il tourner (forum Android, donc tablette ? téléphone ? les deux ?) ? Et le serveur ? Et caetera, et caetera...

Voici le genre de questions aux réponses desquelles vous devez d'abord réfléchir entre vous, puis nous soumettre si quelque chose n'est pas clair.

[regma]

Le problème se situe au niveau des choix pour mon module serveur, choix que je n'arrive pas à déterminer.

Présentation de l'application

Avancement du projet

Module client du jeu à modifier
Ce module dépendra de l'implémentation coté serveur.

Module serveur du jeu à développer
Déterminer quelle technologie serveur pour l'échange de donnée rapide
Déterminer qui (du serveur ou du client) s'occupera du calcul de la distante restante entre les utilisateurs.
Déterminer quel ensemble de technologie serveur (type de serveur, utilisation de Thread, socket) pour effectuer les traitements et mettre en place une session de jeu de 2 utilisateurs.

le genre
Divertissement/Communication : "2 personnes partageant une passion doivent se rencontrer"


la présentation graphique
1 image pouvant changer
3 boutons pour arrêter, redémarrer le jeu ou le reporter à plus tard
1 texte affichant la distance restante entre les utilisateurs





les règles:
Un joueur doit se rendre à l'endroit où le 2eme joueur se trouve.
Chacun des joueurs peut arrêter ou reporter à plus tard le fait de rencontrer l'autre joueur, ils pourront également redémarrer cette rencontre plus tard.


le fonctionnement des mécanismes du jeu
L'application calcule la distance restante entre les utilisateurs grâce à leur position GPS


le fonctionnement d'une partie de jeu:

1. Initialisation du jeu
-initialiser un jeu où 2 utilisateurs participent
-vérifier que les 2 users sont prêt à jouer
-Pour le démarrer j'ai besoin que les utilisateurs s'échangent leur position(latitude, longitude) et ainsi démarrer leur rencontre
-Pour que le jeu puisse fonctionner j'ai besoin que les utilisateurs échangent leur position à chaque fois qu'il bouge.
-Puis les joueurs se rencontrent
-Puis le jeu se termine

2. Permettre à chaque user
-d’annuler le jeu
-d’arrêter le jeu pendant un temps donné
-relancer un jeu arrêté


citez des jeux similaires..
Il n'existe aucun jeu similaire


Combien y'a-t-il de joueurs dans une partie ?
2 joueurs par session de jeu.


À quoi ressemblent les interactions entre joueurs ?
Il y a seulement une interaction graphique que les joueurs peuvent faire qui conduisent à un échange de donnée entre les 2 appareils des joueurs, c'est un clic sur un des 3 boutons ou sur l'image.


Quelle est leur fréquence : est-ce nerveux comme un FPS en deathmatch, ou posé comme une partie d'échecs ?
Le joueur peut seulement appuyer sur une image ou un des 3 bouton qui provoque un changement d'image chez l'autre utilisateur (2 fois maximum puis le jeu se termine)


Combien de parties un serveur peut-il héberger ?
Je prévois une marge pour 200-300 parties.


À quelle fréquence le serveur et ses clients sont-ils supposés communiquer ?
Le serveur doit communiquer à une fréquence importante, la plus rapide qui soit.
Le serveur doit transmettre la latitude et longitude (2 doubles). Cette transmission se fait lorsque le serveur a bien reçu la position de l'utilisateur qui a bougé.
Le serveur doit transmettre cette position aussi rapidement qu'un utilisateur bouge (enfin ce qui s'en rapproche le plus)


Quel est l'ordre de grandeur du volume de données qui doit transiter par le réseau ?
50 octets maximum de données critiques à transmettre pour 1 envoi.

Application cliente déjà codée sans le module de jeu

• Android .APK
• IOS.IPA
• Windows Phone .XAP

Type de système(machine et OS) pour les clients ?

Machines

• smartphone
• tablette

OS

• Android.apk
• IOS.IPA
• Windows Phone .XAP

Type de système(machine et OS) pour les serveurs

Configuration de test

Web
-Type:Apache et PHP installés
-OS: Windows 7

Base de donnée
-Type: Serveur MySQl
-OS: Windows Server 2012

Configuration de production (potentielle)

Web
-Type:Apache et PHP installés
-OS: Windows serveur ou Debian serveur

Base de donnée
-Type: Serveur MySQl
-OS: Windows serveur ou Debian serveur

Note: L'emploi d'un serveur Windows ou Debian est possible selon l’hébergeur choisi. L'utilisation d'un serveur Debian m'obligerait à reconfigurer mes serveurs.



Bonne soirée

[Bousk]

Salut,

un serveur de jeu en PHP ? Pourquoi pas, mais est-il possible d'avoir une connexion persistante avec ça ? Dans mes souvenirs, PHP c'est juste un backend appelé sur requête http pour retourner un résultat. C'est du one-off, ce n'est pas une connexion permanente. Ca a évolué ?
Sinon, node.js c'est pas trop compliqué (j'avais mis une poignée d'heures pour pouvoir démarrer), ou n'importe quoi qui te convient, Google regorge d'exemples. En C++ il y a un lien dans ma signature, mais la partie qui t'intéresserait vraiment est seulement en cours d'écriture, mais select a déjà été introduit.
Quel que soit ton choix, rien d'insurmontable vraiment.
Un client ça contrôle pas un serveur. Ca envoit des requêtes et répond à une solicitation. Le serveur est autoritaire, il a toujours raison.
Si le serveur te dit que ton client doit se trouver en telle position, ton client doit s'y placer, parce que sinon il représente un état faux par rapport au serveur, et donc par rapport à tout le monde autour de lui.
De la même manière, il ne dit pas au serveur "je me trouve ici", il demande s'il peut s'y déplacer. Le serveur accepte ou non et envoit sa réponse. Puis le client réagit à cette réponse.
(en pratique c'est pas exact et plein de mécanismes entrent en jeu pour diverses raisons, mais pour l'instant tiens toi à ça)

Ensuite il faut revoir tes objectifs selon tes compétences et la réalité.
- non tu n'enverras pas la position à chaque fois qu'elle change
> tu l'enverras quand elle aura suffisament changé pour que ce soit probant, au mieux
- relancer un jeu arrêté implique sauvegarde et stockage quelque part
> où ? pourquoi ? comment les utilisateurs peuvent le relancer avec tes 3 seuls boutons ?
- l'échange de données rapides, le plus rapide qui soit, à haute fréquence...
> sur smartphone le commun des mortels n'a pas une couverture 4G ou fibre parfaite, c'est lent et saute souvent
- 50 octets par échange ? pour transmettre 2 doubles ???

Si tu as déjà tout ton truc PHP prêt, pourquoi t'embêter et ne pas juste avoir une requête pour récupérer la position dans une DB, une autre pour la mettre à jour, et basta ? Pourquoi parler de thread, sockets etc quand tu veux faire du http et web request one-off ?
De toutes façons si c'est pour avoir 2 personnes, y'aura aucun problème. Même si par hasard tu te retrouvais avec 300 parties, ça reste 600 connectés, c'est rien même pour un hébergeur gratuit.

[regma]

merci pour ta réponse,

un serveur de jeu en PHP ?

eh bien comme le jeu n'en ai pas vraiment un, c'est à dire pas d'objet graphique qui doivent se déplacer ou de mouvements qui y conduisent, j'ai pensé PHP car j'ai déjà un serveur web avec.

mais est-il possible d'avoir une connexion persistante avec ça ?

Je ne suis pas un expert mais avec les sockets c'est possible.

- non tu n'enverras pas la position à chaque fois qu'elle change
> tu l'enverras quand elle aura suffisamment changé pour que ce soit probant, au mieux.
pourquoi t'embêter et ne pas juste avoir une requête pour récupérer la position dans une DB, une autre pour la mettre à jour, et basta ?

Je comptais mettre à jour la distance restante lorsqu'elle varie de 1m mais, lorsque je fais appel à mes .php pour que le PHP fasse les query ou insert en BDD, l'utilisateur a eu le temps de faire plusieurs mètres, ce qui fausse complétement la distance restante affiché dans l'application, et si les 2 bougent c'est encore pire.

un changement de position sur le client 1 entraine(toutes les 1 à 2sec):
-1 requête sur un fichier.php par le client 1 pour transmettre sa position.
-1 requête insert à la BDD pour enregistrer sa position
-1 requête query à la BDD pour que le client 2 récupère sa position

- relancer un jeu arrêté implique sauvegarde et stockage quelque part
> où ? pourquoi ? comment les utilisateurs peuvent le relancer avec tes 3 seuls boutons ?

où ? je pense que la sauvegarde peut se faire en BDD pour le coup.

pourquoi ? eh bien si un utilisateur:
-a envie d’arrêter le jeu, il peut y mettre fin grâce au bouton annuler.
-a envie de remettre à plus tard cette session de jeu, il peut le faire par le bouton reporter.
-a envie de relancer une session (au préalable reporter) il pourra le faire avec le bouton relancer.

comment ? en communiquant avec le serveur qui pourra envoyer une notification au client pour lui dire que sa pair souhaite relancer le jeu.
Précisément je ne sais pas comment puisque je n'arrive pas à décider la mise en place de cette partie coté serveur.

- 50 octets par échange ? pour transmettre 2 doubles ???

Je me suis donné de la marge.

Pourquoi parler de thread, sockets etc quand tu veux faire du http et web request one-off ?

Je parle de Thread ou de socket car:
-mon application a besoin pour démarrer que les clients se synchronisent pour vérifier si les 2 joueurs sont prêt à jouer et soient bien devant leur écran, puis aussi gérer les interruptions du réseaux.
-recevoir et transmettre leurs changements de positions dans un délai relativement cours, voilà pourquoi je parles de thread ou socket afin de pouvoir gérer cette multitude de réception de nouvelle position sans devoir effectuer 3 appels successifs à la BDD pour chaque changement.
-ce serait plus simple de boucler sur un traitement serveur, enfin c'est comme çà que j'y ai réfléchi.
-les thread me permettrait par exemple de récupérer les positions des utilisateurs et de calculer la distance restante sans devoir enregistrer ces positions au préalable(enfin si j'ai bien compris)

Je ne veux pas forcément faire du mode déconnecté, voilà pourquoi je parle de socket, de plus pour transmettre de messages c'est possible client-> serveur et serveur->client.

De toutes façons si c'est pour avoir 2 personnes, y'aura aucun problème

Quand j'ai faits mes tests en local, pour seulement une pair de joueur qui bougent en même temps pour se rejoindre, lorsque je passais par des requêtes insert et query en BDD cela faisait monté l'utilisation du réseau à 80% sur mon serveur et le CPU à quasiment la même chose.
J'ai tenté de mettre mon serveur MySQL sur une autre machine physique et cela n'a rien changé au réseau, seul la charge CPU baissait de 10 à 20%. Les temps de mise à jour de la distance restante était aussi long voir parfois inexistant.


Par rapport à l'utilisation de thread et/ou socket, j'ai essayé de donner une réponse relative à ce que j'avais lu. Je suis novice pour ces utilisations d'où mon post.

[Mat.M]

Autrement dit, comment spécifier dans la requête, j'envoie cette information pour le thread 1 qui est en attente ?[/INDENT]

je réponds rapidement à la louche désolé si cela a été écrit avant, dans un jeu client serveur on passe directement par les sockets pour des questions de performances.
Ensuite les sockets ne font qu'envoyer de l'info bufferisée ( bref des char dans un tampon)
Donc dans ce tampon de donnée il suffit d'écrire un paquet d'infos, nom du client , top horaire de l'envoi de l'info heure: minute: seconde:millisecondes etc....
ensuite je conseille vivement de faire une classe C++ CClientThread qui aggrége et instancie tout cela.
Si tu as beaucoup de CClientThread tu peux les mettre dans un tableau.

[vertebre]

ok, je vais faire des tests et je reviendrai poser mes éventuelles questions.

merci

[vertebre]

coucou tous le monde,

Je suis partie sur NodeJs avec socket.io et je dois dire que c'est un super conseil thanks