Hello, bienvenue parmi nous.
Alors, c'est quoi que tu appelles simulations au juste ?
Sinon, je crois bien que lorsqu'un navigateur reçoit un header de redirection il stoppe sa requête actuelle pour faire une requête sur la nouvelle URL. Mais peut-être que non.
Si oui, le serveur a les moyens de le savoir (connexion interrompue), et là il faut voir si php peut recevoir un signal
bon je viens de trouver ça, donc par défaut le script se stoppe mais on peut l'en empêcher.
source
Par contre :
Si je lis bien, ça veut dire que ma fonction de fermeture se déclenche non pas lors de la coupure de connection mais lorsque je refais une requete, et là elle va être exécutée une seconde fois si le script se déroule en entier.
Non seulement ce n'est vraiment pas pratique, mais c'est carrément bancal.
Je crois surtout que la doc se goure et que la fonction est lancée lors de la fermeture de la connexion. ça me paraît mille fois plus logique.
Bon, en tout cas ton truc est possible, mais on ne sait pas si le navigateur va effectivement couper la connexion, et à mon humble avis ce n'est pas une bonne solution car tu dois lancer une première requête pour lancer la "simulation", et une seconde si tu veux récupérer un résultat.
Mettre en place un système de push revient plus ou moins au même (deux requêtes ou une seule (polling/long-polling) et est beaucoup plus pratique car on peut bâtir dessus des systèmes de communications plus forts et plus simples.
Et tout cela se fait sans serveur dédié. Je ne rejoins pas Sephi qui dit dans son article que le serveur dédié est obligatoire, notamment quand tu veux faire avec PHP. La pluspart des jeux que je vois ici proposent des scripts qui répondent instantanément à une action, ou qui regardent dans une base de données l'état général du jeu pour savoir ce qu'ils doivent faire.
Par contre je le rejoins quand il dit que c'est un must, car un daemon fait dans un langage performant t'offre le push, l'état du jeu et d'autres 'goodies' de façon simple. Pour le prix que ça coûte en général je n'ai pas hésité. T'en as qui vont claquer 200 € par mois pour leur passion, genre le ski nautique, et moi ça me revient à 85 € / an avec un VPS sympa.
Alors, c'est quoi que tu appelles simulations au juste ?
Sinon, je crois bien que lorsqu'un navigateur reçoit un header de redirection il stoppe sa requête actuelle pour faire une requête sur la nouvelle URL. Mais peut-être que non.
Si oui, le serveur a les moyens de le savoir (connexion interrompue), et là il faut voir si php peut recevoir un signal
bon je viens de trouver ça, donc par défaut le script se stoppe mais on peut l'en empêcher.
Citation :Vous pouvez en outre décider si vous voulez que la déconnexion d'un client provoque l'arrêt de votre script. Il est parfois pratique que vos scripts continuent à s'exécuter jusqu'à la fin, même si le client n'est plus là pour recevoir les informations. Cependant, par défaut, le script s'arrêtera dès que le client se déconnecte. Ce comportement peut être modifié avec la directive ignore_user_abort dans le fichier php.ini ou bien avec la directive Apache php_value ignore_user_abort du fichier Apache httpd.conf ou avec la fonction ignore_user_abort(). Si vous ne demandez pas à PHP d'ignorer la déconnexion, et que l'utilisateur se déconnecte, le script sera terminé. La seule exception est si vous avez enregistré une fonction de fermeture, avec register_shutdown_function(). Avec une telle fonction, lorsque l'utilisateur interrompt sa requête, à la prochaine exécution du script, PHP va s'apercevoir que le dernier script n'a pas été terminé, et il va déclencher la fonction de fermeture. Cette fonction sera aussi appelée à la fin du script, si celui-ci se termine normalement. Pour pouvoir avoir un comportement différent suivant l'état du script lors de sa finalisation, vous pouvez exécutez des commandes spécifiques à la déconnexion grâce à la commande connection_aborted(). Cette fonction retournera TRUE si la connexion a été annulée.
source
Par contre :
Citation :Avec une telle fonction, lorsque l'utilisateur interrompt sa requête, à la prochaine exécution du script, PHP va s'apercevoir que le dernier script n'a pas été terminé, et il va déclencher la fonction de fermeture. Cette fonction sera aussi appelée à la fin du script, si celui-ci se termine normalement.
Si je lis bien, ça veut dire que ma fonction de fermeture se déclenche non pas lors de la coupure de connection mais lorsque je refais une requete, et là elle va être exécutée une seconde fois si le script se déroule en entier.
Non seulement ce n'est vraiment pas pratique, mais c'est carrément bancal.
Je crois surtout que la doc se goure et que la fonction est lancée lors de la fermeture de la connexion. ça me paraît mille fois plus logique.
Bon, en tout cas ton truc est possible, mais on ne sait pas si le navigateur va effectivement couper la connexion, et à mon humble avis ce n'est pas une bonne solution car tu dois lancer une première requête pour lancer la "simulation", et une seconde si tu veux récupérer un résultat.
Mettre en place un système de push revient plus ou moins au même (deux requêtes ou une seule (polling/long-polling) et est beaucoup plus pratique car on peut bâtir dessus des systèmes de communications plus forts et plus simples.
Et tout cela se fait sans serveur dédié. Je ne rejoins pas Sephi qui dit dans son article que le serveur dédié est obligatoire, notamment quand tu veux faire avec PHP. La pluspart des jeux que je vois ici proposent des scripts qui répondent instantanément à une action, ou qui regardent dans une base de données l'état général du jeu pour savoir ce qu'ils doivent faire.
Par contre je le rejoins quand il dit que c'est un must, car un daemon fait dans un langage performant t'offre le push, l'état du jeu et d'autres 'goodies' de façon simple. Pour le prix que ça coûte en général je n'ai pas hésité. T'en as qui vont claquer 200 € par mois pour leur passion, genre le ski nautique, et moi ça me revient à 85 € / an avec un VPS sympa.