13-03-2010, 08:26 PM
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
.
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
.