Comment faire un CRON dynamique avec un serveur mutualisé?

[archANJS]

De toute manière, le problème ne se pose pas, si tu fais bien les trucs.

Il n'y aura pas de lag, car tu ne dois pas te reposer sur la queue ou tout autre système que tu utilises. La queue sert à traiter les informations quand il n'y a personne de présent.

Si le joueur se connecte et va sur sa carte, tu dois checker à ce moment (quelque soit la solution utilisé, at, queue, ou autre) si les bâtiments sont finis ou non et aussi afficher le temps restant en le calculant à ce moment là. Si le bâtiment est finis bah tu affiches qu'il est terminé, donc le joueur ne le verra pas non terminé et tu vires de la queue le fait que le bâtiment était en construction.

De plus tu peux faire ça très simple, tu fais une classe ProcessQueuePlayer, et une classe ProcessQueue, le script qui tourne en cron toutes les 1mn va lancer la classe ProcessQueue pour traiter la queue, pour chaque ligne de joueur qu'elle trouve, elle fait ProcessQueuePlayer pour traiter la queue pour le joueur spécifique.

Du coup, quand le joueur se connecte sur le site, tu lances à chaque fois dans tes pages web la classe ProcessQueuePlayer qui ferait exactement le même traitement que le cron. Enfin à quelques détails près, comme le fait de ne pas envoyer de mail pour alerter de la fin de construction

C'est ainsi qu'il faut faire; le cron étant là seulement pour assurer que le monde ne se "fige" pas lorsque aucun joueur n'est connecté.

Ainsi, prenons l'exemple d'un wargame médiéval:

- Le "worker" dit manuel (à l'affichage des pages, donc quand le joueur est connecté) effectue les actions de la QUEUE spécifique au joueur lui-même (construction de bâtiments, création d'unités, mises à jour des ressources), mais également de celle des joueurs avec qui il est en interaction; si j'attaque un joueur lambda et que je remporte, il faut que ses ressources soit mises à jour pour savoir ce que je vais piller...

- Le "worker" dit automatique (ici ton cron) effectuera bien sûr les actions avec un léger décalage, mais ça ne pose pas de problèmes, puisque ça n'a d'impact sur rien. Et puis, qu'est-ce que le joueur en a à faire que son bâtiment ce soit terminé à 12:00:00 au lieu de 11:59:58, s'il n'était pas connecté? Strictement rien, en fait.

---

La meilleure des solutions restant bien sûr d'utiliser des vrai workers et des QUEUES, style Resque bien sûr ^^

[niahoo]

ben ouais mais quand tu affiches ta page tu regardes les constructions en cours et tu prévois d'aller chercher l'info qu'il faut 15 secondes après

[Argorate]

A mon avis vous confondez deux méthodes: (en tout cas, je ne comprends pas^^)

-il y a celle que j'ai actuellement: l'utilisateur déclenche l'action quand il affiche la page de jeu (et que le délai de construction est passé)

-et il y a l'autre méthode (à laquelle j'aspire), qui est de rendre ces taches asynchrone en passant par une tache planifié qui enlève ce traitement (qui ralenti la navigation du navigateur) en l’exécutant seul, de son coté. Sauf qu'il faut donc que ça se fasse à la seconde prêt pour pas qu'il y est de problème de décalage.
Deux cas sont alors possible:
_le joueur rafraichit avant: construction pas effectuer et on lui dit qu'il reste X temps (même si c'est 1 seconde, c'est pas grave)
_Soit le joueur rafraichit après et voit le bâtiment construit

(après le cas bâtard du "je rafraichie en même temps que le cron qui a besoin de qq milliseconde pou s’exécuter" et qui arrive trois fois l'an, je m'en fiche totalement... ce n'est pas le problème que je pose sur ce forum. Pour ce cas, le joueur rafraichira une nouvelle fois et voilà, c'est un cas à part, sans solution et qui ne m'interesse pas puisque ça n'arrivera jamais [peut être une fois pour me contre dire]).

Donc je ne comprend pas l'idée de mélanger les deux concepts comme certains le suggère (ni même l’intérêt, alors qu'une seule des deux méthodes marche, pourquoi avoir les deux?)?

[srm]

Réfléchis.

[Damocorp]

Je me suis aussi souvent cassé la tête sur ce genre de problème. Et finalement, depuis peu passé sur dédiée, je suis malheureusement encore sur le principe de cron + vérif provenant de l'utilisateur en attendant d'apprendre ce système de queue et de worker dont j'entends souvent parler ici. Mais le plus petit dédiée d'ovh est à 18 euros par mois, c'est pas énorme et il réponds plus vite que mon easyphp sur mon pc, même aux heures de pointes ! ( ok Linux c'est tout un truc à apprendre ^^ j'en ai chié mais faut se lancer un jour ou l'autre ).

De plus, étant sur mutualisé d'ovh il y a peu, j'ai pu voir que le cron ne peut être lancer que par heure minimum. Pas de réglage plus bas. Alors un cron à la minute sur mutualisé d'ovh tu peux oublier.
Le mutualisé est bien trop court en paramétrage pour pouvoir faire ce que tu souhaite.

[Marc15]

Ça dépend aussi du mutualisé.

Sur le mien les CRON peuvent être paramétrés à la minute.

[Damocorp]

C'est bon à savoir, mais perso, j'ai gouté à Linux Debian sur mon serveur dédiée, et je suis pas prêt de retourner sur un mutualisé !

et vu son problème, le mutualisé même avec Cron toutes les minutes ne l'aidera pas
La meilleure des solutions restant bien sûr d'utiliser des vrai workers et des QUEUES, style Resque bien sûr

Et la sur du mutualisé c'est mort


Je pense que la solution pour lui se résume en deux choix :

- Mutualisé avec cron à la minute + le script envoyer par l'utilisateur
ou
- le dédié et la configuration qu'il souhaite pour pouvoir retirer son script de la page utilisateur.


Après cela je vois bien une autre solution en plusieurs tables mais c'est bordélique je trouve :

- En gros la construction va dans une table
- la minute précédent la fin, le CRON le mets dans une table provisoire des bâtiments à afficher comme construit
- La minute d'après le cron supprime la ligne provisoire et l'insert correctement dans la table des constructions réaliser.

Niveau affichage il suffira de lier la table des constructions fini avec celles des constructions fini provisoirement et de gérer le temps de fin de construction uniquement sur l'affichage. Mais en cas ou les constructions entre en interactions avec d'autre script ( genre attaque de base ) ça risque de posé des problèmes aussi.

edit : ça m'intéresse car je compte bien apprendre et utiliser ce système de queue et de worker dont j'entends souvent parler. Toute solution ou piste est donc sympa à prendre

[Sephi-Chan]

edit : ça m'intéresse car je compte bien apprendre et utiliser ce système de queue et de worker dont j'entends souvent parler. Toute solution ou piste est donc sympa à prendre

Tout est dans PHP Resque et PHP Resque Scheduler (si tu bosses avec PHP, bien sûr).

[Argorate]

Réfléchis.

Tu te doutes bien que j'y ai réfléchis pour mon jeu^^

Là maintenant on est sur un forum pour en discuter, donc j'attends toujours qu'on réponde a mon dernier post:

Quel utilité d'implémenter deux méthodes quand une suffit (synchrone et asynchrone cité plus haut)?

[archANJS]

L'utilité est simple selon moi: si on prend qu'une seule des deux techniques, séparément il peut y avoir des lacunes.

"Manuellement": Lorsqu'il n'y a aucune joueur de connecté, le jeu fige.
"Automatiquement": Il y a un décalage.

Donc les deux solutions ensemble, tout est réglé. Et ce n'est pas bien difficile à intégrer, puisqu'au fond les deux font la même chose.

Mais bon, si l'un des deux "problèmes" ne te dérange pas, il y a aucun souci alors ^^