Un daemon… En PHP ?

[Ieyasu]

Bonjour à tous !

Alors comme dis dans ma présentation, j'hésite encore à me lancer dans l'aventure d'un jeu par navigateur, car je suis confronté à un dilemme.

Quelques soit les prétentions du jeu, je voudrais que des scripts travaillent ma base de donnée de manière assez intense.

Admettons que mes joueurs déclenchent des évènements temporisés grâce à des timestamps, et que je gère une "pile" d'évènements dans une table (pour faire simple).

Les solutions :

- Exécuter des scripts lorsque les joueurs se connectent et naviguent...
Avantages :
* Facile à mettre en place
* Suffisant pour certains jeux, ne necessitant pas un rafraichissement trop important des
informations sur la base de donnée.

Inconvénients :
* Très difficile à maintenir... Le code devient vite un bric à brac infâme.
* Moins il y a de joueurs, plus leur navigation sera pollué par l'exécution de ces scripts.
* Ne permet pas d'implanter certains type d'évènements généré par l' "IA" du jeu à des
moments très précis.

- Lancer des exécutions régulières via cron
Avantages :
* Précis et efficace, permet de lancer des scripts de "mise à jour"
* Ne nécessite pas ou peu de précautions ou de programmation supplémentaire

Inconvénients :
* Nécessite un accès aux commandes du serveur, ou un hébergement suffisamment souple.
* Sur des scripts exécuté une seule fois par jour, grosse manipulation de la base de donnée.
* Ne peut pas exécuter de script de manière réactive, délai minimum d'une minute...

- Programmer un Daemon qui tourne en tache de fond sur le serveur
Avantages :
* Exécutions de script "à la demande", et surtout "au besoin". permet de lancer des scripts
de manière réactive en fonction d'évènements PJ ou PNJ sans délai.
* Pas de grosse mise à jour quotidienne, mais un rafraichissement permanent de la base
de donnée.
* Pas de pollution de la navigation des utilisateurs par des scripts opportuniste.

Inconvénients :
* Nécessite un accès poussé au serveur (dédié).
* Nécessite un surplus de programmation.




Voila très globalement mon raisonnement pour dégrossir ma réflexion, et étant donné que le jeu que je désirerais coder (si je m'y lance) serait rythmé par de nombreuses interventions de l'IA et une gestion dynamique des ressources / prix je pense qu'un Daemon serait la solution.


Bien sur, j'avais de prime abord pensé à un Daemon en dur, peu importe le langage (C, C++, java...) mais en me renseignant j'ai trouvé quelques topics suggérant qu'un Daemon php pouvait être tout à fait performant si l'on prenait certaines précautions pour éviter les fuites mémoires.


Je voudrais donc vos suggestions et avis à ce sujet, pensez vous qu'un Daemon en php puisse être une bonne façon d'appréhender un jeu php par navigateur?
Quels en sont les limites d'après vous?

Merci à vous !

[christouphe]

quitte à faire un deamon, autant le faire en C/C++ oublie le PHP pour ça. 'fin c'est mon avis. Penches toi vers les Treads :


http://www.copix.org/index.php/wiki/Thread
http://www.developpez.net/forums/d343269...AAAAAGFAAA=

Bon les autres langages (JAVA,C,C++) je les ai pas sous la main, mais la doc est en ligne

[Ieyasu]

Bonjour Christouphe, c'est de cette façon là que j'entendais créer un "Daemon", en gérant différents processus via un script "père".
Avec une base comme cella ci :
http://lindev.fr/index.php?post/2009/02/...-en-Daemon

N'étant pas une bête de compétitions en c++, je garde l'espoir php, mais si il faut plonger...

[Argorate]

Salut, je pense que c'est ce prendre la tete pour rien mais bon^^

pour la première méthode :

Inconvénients :
* Très difficile à maintenir... Le code devient vite un bric à brac infâme.

Si tu juges que tu codes mal et/ou que tu n'as pas suffisamment d'expérience et/ou de rigueur pour ne pas que se soit un "bric à brac infâme", c'est a toi de juger de tes limites d'organisation, cependant ne généralise pas. Il est très facile de mettre de l'ordre avec des include au bon endroit et un peu de d'organisation.

* Moins il y a de joueurs, plus leur navigation sera pollué par l'exécution de ces scripts.

Je ne comprends pas. Étant donner que tu met a jour uniquement le joueur qui se connecte, le nb de joueurs n'a rien avoir et le fait d'updater un joueur est justement transparent, a la différence d'un cron qui fais tout d'un coup et qui peut donc ralentir grandement le serveur durant la MAJ.

* Ne permet pas d'implanter certains type d'évènements généré par l' "IA" du jeu à des
moments très précis.

Ah bon? pourquoi? qu'es ce qui t'empêche de faire cela? tu as un exemple? je ne vois pas trop^^

Donc pour ma part je pense que la solution la plus transparente et la plus facile a mettre en place c'est la mise a jour du joueur quand il se connecte (ou quand un autre joueur connecté fais une action sur lui).

Qu'es ce tu en penses?

[niahoo]

Hmm le coup du Fork avec php ça ne me plait pas, je ne ferais pas confiance à ce langage pour ça, et surtout sur du mutu genre OVH ça ne passe peut-être pas, notament l'histoire d'écoute de ports.

Maintenant rien ne t'empêche de lancer le script en boucle depuis ton poste en faisant des requêtes avec Curl ou un navigateur.

Quelques pistes :
Laisser le programme tourner en boucle indéfiniment et n'envoyer de réponse à la requête que quand il y a une erreur. Bloquer le script en cas d'erreur et attendre qu'il soit relancé. Il ne se relance pas seul.

(Re)Lancer le script à partir de chez toi, de ton panneau d'admin, avoir un script externe pour traiter les erreurs et lancer certaines tâches en priorité en fonction de celles-ci.

Prévoir un moyen d'interrompre le script quand on veut, notamment quand on a perdu sa connexion internet, au lieu d'attendre qu'il tombe sur une erreur.

Le laisser planter en beauté au lieu de passer 3 mois à coder un gestionnaire d'erreurs super complexe qui va essayer de corriger les erreurs alors que ce n'est pas le boulot de ce script.
Par contre, avoir un gestionnaire d'erreurs qui remplace les erreurs natives pas un truc ergonomique genre JSON, XML, headers HTTP, ou autre structure de ton cru pour permettre à ton superviseur de les lire et de les traiter est bien pratique.

Du coup tu peux utiliser les cron pour relancer ton script, mais sur OVH par exemple on dirait que le minimum de périodicité est 1 heure. donc si ton script plante à 15h01 il faudra attendre 59 minutes avant qu'il se relance. Marquer dans un fichier que le script est déjà en cours d'exécution s'il n'est pas planté, afin d'éviter que le cron ne le relance.

Est-ce que le cron va être bloqué du fait que le cron ne se termine pas ? Dans ce cas là ça revient à ta solution il faut utiliser un fork, ou une requête apache.

Dégoter un serveur dédié et remplacer ton navigateur/cron par un vrai deamon.

[Ieyasu]

Salut, je pense que c'est ce prendre la tete pour rien mais bon^^

pour la première méthode :

Inconvénients :
* Très difficile à maintenir... Le code devient vite un bric à brac infâme.

Si tu juges que tu codes mal et/ou que tu n'as pas suffisamment d'expérience et/ou de rigueur pour ne pas que se soit un "bric à brac infâme", c'est a toi de juger de tes limites d'organisation, cependant ne généralise pas. Il est très facile de mettre de l'ordre avec des include au bon endroit et un peu de d'organisation.

Je me suis peut-être mal exprimé, je ne remet pas en cause ma façon de coder, sans quoi il faudrait que je change de boulot :non:
De plus, ce sujet n'est ni un tutoriel ni de la propagande, il ne reflète que ma vision des choses, et les soucis que je rencontre, donc je ne généralise pas, très loin de la.

* Moins il y a de joueurs, plus leur navigation sera pollué par l'exécution de ces scripts.

Je ne comprends pas. Étant donner que tu met a jour uniquement le joueur qui se connecte, le nb de joueurs n'a rien avoir et le fait d'updater un joueur est justement transparent, a la différence d'un cron qui fais tout d'un coup et qui peut donc ralentir grandement le serveur durant la MAJ.

Peut être parce qu'il ne s'agit pas de mettre à jour seulement les informations concernant le joueur qui se connecte.
Envisageons un environnement dynamique dans lequel deux joueurs peuvent interagir indirectement, sans le vouloir.
Le moteur du jeu est supposé gérer ces interactions, mais également des interactions PNJ/PJ.
il ne s'agit pas simplement de dire "votre mine de cristal vous as rapporté x ressources".
Bien entendu, à moins d'arriver à des volumes d'informations monstrueux, cela ne devrait pas entraver la navigation outre mesure, a condition d'avoir suffisamment de connexion régulière, sans quoi la somme d'évènements liés aux actions des IA sera trop importante.

* Ne permet pas d'implanter certains type d'évènements généré par l' "IA" du jeu à des
moments très précis.

Ah bon? pourquoi? qu'es ce qui t'empêche de faire cela? tu as un exemple? je ne vois pas trop^^

Donc pour ma part je pense que la solution la plus transparente et la plus facile a mettre en place c'est la mise a jour du joueur quand il se connecte (ou quand un autre joueur connecté fais une action sur lui).

Qu'es ce tu en penses?

Le jeu dans lequel j'envisage de me lancer serait une simulation.
En gros commerce, combat, construction, des concepts récurrents.

L'univers sera entièrement soumis aux actions des joueurs, mais également de leur homologues PNJ, car le jeu contiendrait des "IA" occupant le même rôle que les joueurs, afin de dynamiser l'univers.

L'IA "a" pourrait faire demi-tour car l'IA "b" vient de détruire le dépôt de vente vers lequel elle allait.
L'IA "c" interceptera l'IA "b" car celle ci changera finalement d'itinéraire.
L'IA "d", opportuniste profitera du combat pour ramasser les ressources encore récupérable après la bataille.

Lorsqu'un joueur se connecte, si personne ne c'est connecté depuis x heures, celui-ci sera dont en charge du script qui va générer toute la vie artificielle et les évènements depuis la dernière connexion en date.

Admettons que le jeu contiennent quelques centaines de joueurs IA, cela constitue une somme de calcul assez conséquente.
Calculer les trajets, les rencontres, les interactions, les transactions de chacun, les fluctuations de prix qui en découlent, chaque action que peut entreprendre l'IA peut générer des réactions des autres PNJ.
Comme par exemple pour l'exemple précédent, comment gérer les changements d'attitude des IA en fonctions de leur actions?
Un processus qui qui gèrerait ces interactions à intervalle court et régulier serait une très bonne alternative.

Admettons maintenant cette structure simpliste pour le jeu:
* Chaque évènement est simplement représenté en base de donnée par un script à lancé, ses paramètres et l'heure précise de lancement.
Le traitement des informations serait géré de la sorte : Un script met le jeu à jour en exécutant les scripts de la pile par ordre d'heure d'exécution, jusqu'ici rien d'incohérent.

Seulement, l'exécution d'un évènement pourra modifier les évènements suivant.
Donc après chaque exécution de script, il faudra vérifier ses conséquences sur les autres évènements de la pile.
Malheureusement, ces interactions ne peuvent pas être anticipés, car elles dépendent d'élément extérieurs : les joueurs, et doivent être calculés après chaque évènement.

Dans une simulation sans joueurs, aucun soucis, dans un jeu sans IA, aucun soucis, mais lorsque les deux se côtoient, il faut relancer un script de mise à jour du comportement de l'IA après chaque modification de ses variables d'environnement pour que les comportements restent cohérent.

Alors ce n'est que mo inquiétude, mais je me dis que lorsqu'un joueur se connectera après 6 ou 7 heures sans connexion, qu'il lancera un script devant calculer le comportement d'un bon gros paquet d'IA sur tout ce temps, ca risque de poser un gros problème...


Du haut de ma modeste expérience de développeur, je ne vient que pour vos conseils, peut-être que j'appréhende mal mon idée de la gestion des évènements des IA et que le vrai problème est ici, éclairez moi


De mes lectures, un Daemon semblait être un must have, une combinaison de cron + script déclenché par les utilisateurs pourrait peut-être faire l'affaire.

Paye ton pavé :rip:


@niahoo : Je compte prendre un serveur dédié, donc je peux envisager pas mal de choses, les hébergements mutualisés sont effet très restrictifs.

[Sephi-Chan]

Je pense que ton approche est la bonne. Je trouve que c'est sale de gérer les événements au grès de la navigation des joueurs, je préfère séparer mes couches de code.

Concernant ton daemon, le faire en PHP te permettrait de réutiliser tes couches modèles. Le problème, c'est qu'il est difficile de gérer ce genre de processus qui ont une durée de vie très longue (concernant la mémoire, notamment).

As-tu regardé du côté des outils comme Resque (et leur équivalent PHP, bien sûr) ?


Sephi-Chan

[Ieyasu]

Si je comprend bien, Resque est une librairie permettant de temporiser l'exécution de scripts Ruby.

J'ai déjà effleuré ruby du doigt avec le bouquin des éditions "Ressources informatiques", c'est une façon très ludique de coder, très propre à mon goût mais je dois avouer que je suis rapidement retourné à php.

peut-être existe t-il l'équivalent php, je vais me renseigner.

[Sephi-Chan]

Resque est un système de mise en queue de tâches. Tu peux ensuite avoir plusieurs workers qui traitent ces tâches (c'est adapté aux infrastructure distribuées, les workers peuvent être sur plusieurs machines).

PHP semble proposer un port de Resque nommé… PHP Resque ! xD


Sephi-Chan

[Ieyasu]

Hummm étant donné la structure même d'un jeu par navigateur je ne sais pas si cela convient parfaitement à ma problématique.
Effectivement je dois prioriser et temporiser l'exécution de taches, mais aucune infrastructure distribuée.

En farfouillant, il semble que php ne soit définitivement pas multi-thread, mais multi-process, c'est déjà pas mal.

L'alternative PCNTL semble assez solide si le tout est bien codé...

Je vais essayer de retourner tout ca et de faire quelques test...