[PHP] Resque ou Rediska et Redis : je rame complétement...

[php_addict]

De toute façon je compte utiliser redis pour les traitements lourds.
Mais en aucun cas ça ne dispense du bout de code censé faire comme si l'action se déroulait a l'heure prévue, même si elle est exécutée après!

Conclusion: ma méthode est bonne, et un système de résolution comme le mien peut être utilisé a la demande via un appel a une méthode de ma lib update (avec param pour l'user a update, ou faire l'appel depuis redis, en passant ou pas le paramétre)

je ne suis pas certain de comprendre, tu compte t'y prendre comment finalement avec ta résolution d'action? déclenchement lors d'un rafraichissement de page ou en background ?

il y a un truc super étrange avec redis quand on lui envois la commande SET via le port adéquat:

ceci ne fonctionne pas

$cmd = "SET $key $value\r\n";

$this->send_redis_command($cmd );

, il faut faire

$cmd = "SET $key " . strlen($value) . "\r\n$value\r\n";

$this->send_redis_command($cmd );

c'est incompréhensible pour moi. source : http://petewarden.typepad.com/searchbrow...n-php.html

[Sephi-Chan]

De toute façon je compte utiliser redis pour les traitements lourds.
Mais en aucun cas ça ne dispense du bout de code censé faire comme si l'action se déroulait a l'heure prévue, même si elle est exécutée après!

Conclusion: ma méthode est bonne, et un système de résolution comme le mien peut être utilisé a la demande via un appel a une méthode de ma lib update (avec param pour l'user a update, ou faire l'appel depuis redis, en passant ou pas le paramétre)

je ne suis pas certain de comprendre, tu compte t'y prendre comment finalement avec ta résolution d'action? déclenchement lors d'un rafraichissement de page ou en background ?

Cette discussion n'a aucun sens. Avant de se demander comment il fait, il faudrait déjà savoir ce qu'il doit faire.

il y a un truc super étrange avec redis quand on lui envois la commande SET via le port adéquat:

ceci ne fonctionne pas

$cmd = "SET $key $value\r\n";

$this->send_redis_command($cmd );

, il faut faire

$cmd = "SET $key " . strlen($value) . "\r\n$value\r\n";

$this->send_redis_command($cmd );

c'est incompréhensible pour moi. source : http://petewarden.typepad.com/searchbrow...n-php.html

Désolé, je préfère la simplicité.

$redis->set($key, $value);

C'est marrant ton kiff de toujours te mettre des bâtons dans les roues.

[php_addict]

C'est marrant ton kiff de toujours te mettre des bâtons dans les roues.

comme je te l'ai dis, je suis par nature extrêmement curieux, j'aime bien comprendre comment fonctionne les choses et je n'aime pas me limiter à "je clic sur un truc, ca marche, je vais pas chercher à comprendre pourquoi ca marche"

ca ne te donne pas envie de comprendre pourquoi la commande SET bug quand on l'envois via la socket?

vous allez rire je viens de tomber la dessus : http://www.php.net/manual/fr/book.gearman.php mais je n'arrives pas à savoir si il y a possibilité de schedulding

[Sephi-Chan]

C'est marrant ton kiff de toujours te mettre des bâtons dans les roues.

comme je te l'ai dis, je suis par nature extrêmement curieux, j'aime bien comprendre comment fonctionne les choses et je n'aime pas me limiter à "je clic sur un truc, ca marche, je vais pas chercher à comprendre pourquoi ca marche"

ca ne te donne pas envie de comprendre pourquoi la commande SET bug quand on l'envois via la socket?

J'ai bien compris. Mais essaye de séparer tes deux activités : comprendre le queueing/scheduling d'une part, implémenter un client Redis de l'autre.

Avoir deux discussions en une sur des sujets qui n'ont rien à voir, c'est assez pénible à lire. Tu peux en revanche ouvrir un topic dédié pour discuter de l'implémentation d'un client Redis.

vous allez rire je viens de tomber la dessus : http://www.php.net/manual/fr/book.gearman.php mais je n'arrives pas à savoir si il y a possibilité de schedulding

Essaye de faire un effort s'il te plaît… Edit : J'ai bien conscience qu'il y a beaucoup de choses nouvelles dans cette discussion et que c'est difficile à appréhender.

• PHP Resque, dont on parle ;
  
• DJJob, qui est également un portage d'un library Ruby ;
  
• Gearman, que je ne connaissais pas jusqu'à aujourd'hui ;
  
• Zend Server Job Queue, qui est payant ;
  

J'ai effectué une recherche complémentaire pour tes queues et il y a plusieurs solutions possibles : AMQPQueue, Gearman, cette article http://kore-nordmann.de/blog/0098_native_job_queue.html etc

J'avais cité Gearman mais lui non plus n'est pas capable de gérer le scheduling.

[atra27]

Je suis tombé la dessus:
https://github.com/kamisama/Cake-Resque

Aucune idée de ce que sa donne mais vu que plus haut il y a une liste des solutions disponibles, je rajoute celle-ci pour ceux qui lirons ce sujet plus tard.

Dommage que c'est pour cakePhp, je maitrise pas ce FW... J'ai pas pu tester

[php_addict]

je n'utilise pas cake non plus...

j'ai toujours un doute quant à l’utilité d'un job queue pour la résolution des actions en fait...car j'ai des actions qui doivent être résolues dans le futur (résolution de combats) et d'autres immédiatement (payre, envois de troupes, etc...)

exemple: l'envoi de troupes est une action

- je clique sur "j'envois mes troupes attaquer"
- je suis rediriger vers une url du jeu, et là l'action doit avoir été résolue, et si avec un système de queue l'action est résolu après la redirection cers l'url en question ca va site être chiant pour les joueurs...

[niahoo]

Le truc c'est que tu ne dois pas aller vers une page qui attend qu'un job soit terminé, sinon pourquoi utiliser une queue puisque le joueur devra là aussi subir des chargements longs (on le chouchoute un peu le joueur là non ?).

Je crois que pour ces actions là, et si tu n'utilises pas ajax mais des rafraichissements de page, tu peux très bien utiliser ton code de base et les résoudre pendant le rechargement. Tu n'utiliserais plus Resque que pour ce qui se finit plus tard.

L'avantage si tu utilises ajax, c'est que tu pourras tout traiter comme si ça se finissait plus tard.

Mais en attendant, n'utilises Resque que pour ce que tu traites vraiment de manière asynchrone.

Ou pas, hein, je sais pas.

[Sephi-Chan]

j'ai toujours un doute quant à l’utilité d'un job queue pour la résolution des actions en fait...car j'ai des actions qui doivent être résolues dans le futur (résolution de combats) et d'autres immédiatement (payre, envois de troupes, etc...)

exemple: l'envoi de troupes est une action

- je clique sur "j'envois mes troupes attaquer"
- je suis rediriger vers une url du jeu, et là l'action doit avoir été résolue, et si avec un système de queue l'action est résolu après la redirection cers l'url en question ca va site être chiant pour les joueurs...

C'est parce que tu n'embrasses pas le modèle asynchrone.

Reprenons ton bouton pour envoyer les troupes. On lui fait faire la même requête, mais en Ajax. Deux cas de figure selon ton jeu :

• Le jeu doit afficher les résultats du combat. Dans ce cas, tu affiches "Attaque en cours…" et dans le job, tu effectues l'action puis tu génères le rapport et tu l'envoies au joueur grâce au push (en utilisant un serveur de push comme Juggernaut, qui utilise également Redis).
  
• Le jeu ne doit pas afficher les résultats du combat (puisqu'il a lieu plus tard). Là c'est encore plus simple : tu affiches seulement un message "L'attaque a été lancée".
  

Enfin bref, avec du queueing et du scheduling, je ne vois vraiment pas comment tu peux douter de l'utilité, ou alors explique clairement pourquoi.

[php_addict]

Enfin bref, avec du queueing et du scheduling, je ne vois vraiment pas comment tu peux douter de l'utilité, ou alors explique clairement pourquoi.

J'ai fait le choix que tout soit considéré comme des actions dans mon jeu, voici tout ce qui est action:

- payer en ressources - action immédiate (construction de bâtiment, recrutement etc...)
- demande de construction de bâtiment - action immédiate (clic sur "construire ce bâtiment")
- Résolution de la construction du bâtiment - action différée
- Envois de troupe - action immédiate (clique sur envoyer l'attaque)
- Résolution de l'attaque - action différée, au moment où l'attaque arrive

donc il y a deux type d'action, des actions immédiatement résolues et des actions différées qui seront résolues plus tard, ce qui permet d'assurer l'intégrité des données (ressources, nb de troupes, etc...), comme par exemple si quelqu'un demande un envois de troupes au moment même où attaquant arrive, ou bien si un joueur paye en ressources au moment même où il se fait piller

le job schedulder correspond bien aux actions différées mais pour les actions immédiates, exemple:

- J'ai 1000 troupes en réserve dans mon village

- Je demande un mouvement de troupe (envois d'attaque), pour ce faire je clique sur "ENVOYER", et là l'action "envoyer troupes" doit être résolue immédiatement car après avoir cliquer sur ENVOYER je ne doit plus voir mes 1000 troupes

- l'action "ATTAQUE" quant à elle sera résolue dans une heure par exemple.

Donc il me semble possible qu'avec un job queue l'action "envoyer" ne soit pas résolue tout de suite (apres clic sur le submit du formulaire) et que donc que le joueur se dise:

"bah...je comprends pas j'ai envoyer 1000 troupes et elles sont encore là (côté client, affichage) (alors qu'elles sont considérées comme en mouvement côté serveur)

j'espère que j'ai été plus clair

[Sephi-Chan]

Ça doit être l'enfer de programmer avec ta paranoia de la race condition.

Actuellement, comment est-ce que tu vérifies que le joueur a assez de ressources pour construire un bâtiment ? Et comment t'assures-tu qu'il n'en a pas perdu entre le moment où tu vérifies s'il a les ressources nécessaires et celui où tu mets à jour les ressources pour payer la construction ?

Après, les actions immédiates légères peuvent être faîtes de manière synchrone — c'est plus simple — mais tu perds alors la protection naturelle que ça fournissait contre tes race conditions imaginaires.