+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Faisable? PHP socket->Flash (/showthread.php?tid=4642)
Faisable? PHP socket->Flash - atra27 - 13-03-2010
Salut all!
J'ai remarqué que la plupart des scripts de chat envoyaient une requete toutes les X secondes au serveur, qu'il y ai ou non un nouveau message...
J'ai pensé a un autre type de fonctionement...
A la connection, le client Flash ou autre, envoie une requete au serveur (du type page.php?pseudo=...)
Le serveur note en bdd le pseudo/IP et autres infos utiles.
Le client flash ecoute ensuite sur le port XXXX (peu importe).
Flash étant du coté client, pas de pb coté ressources serveur.
Quand l'user X veut envoyer un message, flash envoie par get a une page (exemple page2.php?pseudo=XXX&message=blabla)
Cet page ouvre un socket vers le port XXX de toutes les IP des personnes connéctées.
Flash récupére ce message et l'affiche...
Possibilité d'améliorer: si le client ne confirme pas la reception(implémenté dans le protocole TCP il me semble) ->supresson de l'ip concernée en bdd
Faisable? avis? suggestion? Comparaison par rapport a d'atre systemes de chat?
RE: Faisable? PHP socket->Flash - Zamentur - 13-03-2010
C'est possible!
Mais pour un chat tu peux aussi utiliser le procédé comet.
L'idée c'est de faire une demande toutes les minutes, le serveur si il n'y a rien de nouveau met la page en attente ainsi elle est toujours en attente et on peut donc faire du temps reel suffisant pour un chat
L'inconvénient c'est que la page semble toujours en chargement de donnée, et au niveau du serveur çà doit bouffer plus que des sockets, mais j'en suis pas sur
RE: Faisable? PHP socket->Flash - Allwise - 13-03-2010
Salut, oui c'est faisable, c'est autour de ce système que j'avais commencé à développer le moteur de mon jeu.
Un serveur codé en PHP qui tourne sur une boucle infinie d'un côté, en attente de connexions / messages des joueurs d'un côté, et un client en javascript / Flash de l'autre.
J'ai pas eu l'occase de faire des tests de montée en charge mais ça reste un modèle client / serveur classique, donc ça devrait très bien tenir la route.
Par contre ton cheminement m'a l'air un peu confus. Pour ma part ça marchait comme ça :
1° [Serveur] On lance le serveur ( du jeu ou du chat ou peu importe ), qui écoute sur le port donné 1234 et qui est en attente de recevoir un message quelconque.
2° [Client] l'internaute se rend sur la page en question.
3° [Client] Flash se connecte sur le serveur sur le port 1234
4° [Serveur] PHP reçoit le message, accepte la connexion et fait ce qu'il y a à faire lorsque quelqu'un se connecte, par exemple enregistrer son pseudo tout ça et renvoie un message au client "Ok, t'es bien connecté"
5° [Serveur] Le serveur repasse en en mode "J'attends qu'il se passe quelque chose"
6° [Client / Serveur] Le client et le serveur communiquent à travers le socket, pas par GET ni par POST, sinon on perd l'intérêt du modèle client / serveur.
Dans ton cas, si l'utilisateur A écrit quelque chose, Flash va envoyer une message au serveur du genre "PostMsg("bliblablou") ( tu es libre de créer ton propre langage de communication )". Le serveur reçoit le message, et l'envoie à tous les connectés, qui sont stockés dans un tableau. Inutile de stocker les IP en base, puisqu'elles sont déjà enregistrées dans ce même tableau. L'idéal étant, à mon avis, d'avoir une classe Client dans laquelle tu stockes les infos utiles : IP, pseudo, statut... Et à chaque gars qui se connecte, pouf tu ajoutes une nouvelle instance de cette classe dans le tableau des connectés.
Il y a consommation de ressources chez le client car il utilise son browser, enfin ça ça change pas, mais surtout sur le serveur, ça ne change pas non plus en fait
.
RE: Faisable? PHP socket->Flash - atra27 - 13-03-2010
Justement, c'est l'inverse que je propose.
Les clients attendent sur tel port et quand l'un envoie un message, le script php qui s'exécute a ce moment (et uniquement une seule fois a ce moment précis) envoie a tous les clients...
En gros la boucle se trouve coté client et pas coté serveur, qui lui ne fait que renvoyer une requête QUE QUAND un message est a transmettre...
Sa permet d'utiliser ce pour quoi le php est fait, a savoir renvoyer des données suite a une requête d'un browser (sauf qu'ici il renvoie a toutes les IP de la table et pas seulement a celui qui a envoyé la requete)
RE: Faisable? PHP socket->Flash - Plume - 13-03-2010
Ca ressemble au pattern Observateur http://fr.wikipedia.org/wiki/Observateur_(patron_de_conception)
RE: Faisable? PHP socket->Flash - atra27 - 13-03-2010
exactement!
De cette façon, pas de new mess=pas de requête coté serveur.
RE: Faisable? PHP socket->Flash - Allwise - 14-03-2010
Juste du chipotage de terminologie, PHP il est fait pour exécuter du code, qu'il soit orienté browser, traitement d'image, calcul ou autre. Il est pas fait pour renvoyer quoi que ce soit au navigateur, ça c'est le rôle du serveur web, Apache, Lighty, IIS etc.
D'accord, donc en fait dans ton schéma chaque client est serveur. Ça me paraît pas très logique d'inverser les rôles, mais en dehors de ça, si c'est faisable, ça impose aux internautes d'ouvrir un port sur leur machine ; sur leur firewall et / ou sur leur routeur pour certains non ?
RE: Faisable? PHP socket->Flash - atra27 - 14-03-2010
Pas vraiment...
Au lieu d'avoir le serveur ET le client qui scan betement le port (le client pour les messages et le serveur pour les messages/connections) pourquoi ne pas garder que le client.
Le serveur reste serveur dans la mesure ou il centralise quand méme les données, mais ne reste pas en attente inutilement. Quand il ne se passe rien, méme si il y a 1000 personnes de connectées, il ne fait rien.
Par contre lorsque l'on reçoit un message par la méthode classique de GET ou post (similaire a l'appel d'une page reguliére), php envoie le message vers les IP concernées et sur le port concerné.
Les clients qui écoutent sans arret sur ce port reçoivent le packet et le traitent.
On retombe dans un fonctionnement classique de php ou le serveur execute le script uniquement quand il reçoit une demande...(fonctionnement de base d'apache)
Pour info je suis sur un mutualisé plutot souple niveau restrictions et donc pas vraiment envie d'avoir des pb niveau utilisations des ressources.
Et puis méme, je trouve complétement débile de faire une boucle infinie si il y a un message tous les quart d'heure. (heu d'ailleur je trouve débile tout court de faire une boucle infinie en php :p)
RE: Faisable? PHP socket->Flash - Anthor - 14-03-2010
Citation :Et puis méme, je trouve complétement débile de faire une boucle infinie si il y a un message tous les quart d'heure. (heu d'ailleur je trouve débile tout court de faire une boucle infinie en php 10)
Et un daemon c'est quoi à ton avis ?
Tu penses sincèrement, être assez calé techno pour vouloir faire à ton aise des choses que des centaines de dév ont déjà testé dans tous les sens ?
RE: Faisable? PHP socket->Flash - atra27 - 14-03-2010
Je ne connais rien au sockets php et le C est pas tellement accessible sur du mutualisé.
Il faudrait que je jette un oeil coté des scripts cgi...
En attendant personne n'a testé ce type d'architecture?