Discussion :

[grunk]

Tu peux expliquer un peu plus, j'ai pas saisie le rafraîchissement des données, quelles données?

Je partais du principe que tu souhaitais faire quelque chose comme le tuto. Donc les données dont je parle aurait été les données d'état du serveur par exemple , qui n'ont pas forcément besoin d'être lue en permanence.

Je pense que l'idée de daemons n'est pas mauvaise, en limitant leur nombre.
Je voudrais juste lire en permanence ce qu'il a sur la socket afin d'intercepter certains messages.

Si tu n'es pas certains d'avoir le contrôle total sur la config du serveur , tu ne pourras pas le faire en php.
Comme dis précédemment , les hébergeurs mutualisé qui laisse accès au socket ne sont pas nombreux. De plus un daemon tourne en permanence , tu seras donc bloquer par le set_time_limit général défini très bas en mutualisé.

[rgamor]

ok donc la solution serait de détecter l'autorisation d'utiliser les sockets et de proposer la fonctionnalité.

Et du côté des autres langages, comme ASP, CGI?
ou un appel system() qui lancerai un programme qui ferait se boulot

[grunk]

Même problème , l'appel à system n'est pas possible sur du mutualiser. En CGI peut être , j'avoue n'en avoir jamais utilisé.
La détection des socket est une idée mais ça résoudra pas le fait que généralement le temps max d'execution d'un script est de moins de 30 sec. Sans compter les limitation de mémoire généralement assez rude.

Bref un outil comme celui ci , portable partout c'est une utopie

[Benjamin Delespierre]

C'est éventuellement possible si tu fais tourner le logiciel sur une plateforme dédiée, responsable de l'ouverture / fermeture / lecture / écriture sur la socket avec un Daemon comme vu précédemment et que cette plateforme expose un webservice REST ou SOAP attaquable par des sites classiques hébergés sur des serveurs mutualisés.

[grunk]

C'est éventuellement possible si tu fais tourner le logiciel sur une plateforme dédiée, responsable de l'ouverture / fermeture / lecture / écriture sur la socket avec un Daemon comme vu précédemment et que cette plateforme expose un webservice REST ou SOAP attaquable par des sites classiques hébergés sur des serveurs mutualisés.

Je pense que dans l'idée son système permet à l'utilisateur qui l'installe de controler son serveur de jeu. Ce qui voudrais dire que son webservice devrais gérer tous les serveurs de tous ses utilisateurs ... Un peu ambitieux je pense

[rgamor]

c'est en étant ambitieux qu'on apprend le plus de choses, je pense, quand on s'en donne les moyens.

donc si on considère qu'on a accès aux sockets php et qu'on peut modifier le set_time_limit ( d’ailleurs pourquoi ne pourrait t-on pas le modifié sur un serveur mutualisé? avec la fonction set_time_limit() sauf en safe-mode qui est déprécié ???) comment pourrais-je communiqué avec le daemon?

pour la lecture sur le socket je vois bien (en écrivant dans un fichier pour le lire par la suite) mais pour l'écriture dois je utiliser la même méthode mais à l'envers (écrire dans fichier la commande pour ensuite la lire et l'écrite sur la socket) ou existe t-il une solution meilleure?

sinon pour la gestion de la socket j'avais pensé à un select comme dans cette exemple http://broux.developpez.com/articles/c/sockets/#L4-1
qu'en pensez vous?

[Benjamin Delespierre]

c'est en étant ambitieux qu'on apprend le plus de choses, je pense, quand on s'en donne les moyens.

Moi aussi je peux faire des phrases toute faites comme par exemple: "A vouloir s'attaquer dès le départ à un trop gros morceau, on finit par se décourager..." Je pense que tu devrais viser moins haut pour commencer, surtout si tes compétences en programmation son limitées au départ (enfin, ça c'est à toi de nous dire ce que tu sais faire ). On a tous démarré en bas de l'échelle, pour moi par exemple, l'apprentissage de PHP s'est fait au sein d'une équipe sur un projet bateau de site internet.

Mon but n'est pas de décourager mais je pense que l'apprentissage est un processus long qui doit se dérouler par étapes. On a jamais vu un professeur de primaire demander à ses élèves une rédaction de 60 pages sur Bergson.

pour la lecture sur le socket je vois bien (en écrivant dans un fichier pour le lire par la suite) mais pour l'écriture dois je utiliser la même méthode mais à l'envers (écrire dans fichier la commande pour ensuite la lire et l'écrite sur la socket) ou existe t-il une solution meilleure?

PHP te permet de manipuler naturellement les sockets. Pour plus de détails je t'invite à consulter la doc: http://php.net/manual/en/book.sockets.php

[rgamor]

Moi aussi je peux faire des phrases toute faites comme par exemple: "A vouloir s'attaquer dès le départ à un trop gros morceau, on finit par se décourager..." Je pense que tu devrais viser moins haut pour commencer, surtout si tes compétences en programmation son limitées au départ (enfin, ça c'est à toi de nous dire ce que tu sais faire ). On a tous démarré en bas de l'échelle, pour moi par exemple, l'apprentissage de PHP s'est fait au sein d'une équipe sur un projet bateau de site internet.

Mon but n'est pas de décourager mais je pense que l'apprentissage est un processus long qui doit se dérouler par étapes. On a jamais vu un professeur de primaire demander à ses élèves une rédaction de 60 pages sur Bergson.

c'était pas une phrase toute faite! j'aurais cité l'auteur sinon.
Et puis c'est la façon dont je fonctionne, j'ai besoin d'un projet ambitieux pour étendre mes connaissances. Chacun son mode d'apprentissage!

J'ai posté sur ce forum car je n'ai aucune connaissance des bonnes pratiques en rapport avec ce que je voulais faire. Et aussi pour profiter de votre expérience en application web.
Car je pense qu'il y a une grande différence entre savoir coder (code qui fonctionne) et coder correctement (cad selon des design pattern ou des méthodes qui ont faits leurs preuves et donc un code efficace).

Et il y a bien un moment, ou les bases c'est bien, faire des trucs simple c'est bien, mais y'a un moment faut décollé.

Ton lien ne répond pas à ma question, qui était en gros "Comment communique t'on avec le daemon? avec un fichier ou y'a t'il une méthode plus élégante?
Le daemon sert juste à lire la socket et il vaut mieux créer une socket pour chaque demande d'envoie de commande au serveur de jeux?

[Benjamin Delespierre]

Car je pense qu'il y a une grande différence entre savoir coder (code qui fonctionne) et coder correctement (cad selon des design pattern ou des méthodes qui ont faits leurs preuves et donc un code efficace).

C'est tellement vrai Enfin, il ne faut pas non plus ne jurer que par les design pattern, j'avais justement un excellent article là dessus: http://www.croes.org/gerald/blog/nut...9/#comment-529

Ton lien ne répond pas à ma question, qui était en gros "Comment communique t'on avec le daemon? avec un fichier ou y'a t'il une méthode plus élégante?

Comme mentionné dans l'article sur les daemons cité plus haut; le meilleur moyen de communiquer avec un daemon est d'utiliser les signaux posix. S'il s'agit de piloter un daemon sur une machine externe, on peut toujours envisager une couche de webservices capable d'envoyer ces signaux sur demande extérieure.

Le daemon sert juste à lire la socket et il vaut mieux créer une socket pour chaque demande d'envoie de commande au serveur de jeux?

Plus exactement, le daemon garde la socket ouverte et travaille dessus.

[rgamor]

je suis tout à fait d'accord avec l'article.

mais avec les signaux on ne peut pas transmettre une chaîne de caractères, donc quand le daemon reçoit un signal particulier il faut qu'il ouvre un fichier pour y cherché la commande?

[rgamor]

avec une socket server dans le daemon est une bonne solution?