raphlight

Bonjour,

J'aimerais faire un système de points périodiques sur un site.

Je m'explique, par étape, ayez le courage de lire svp ^^ :

J'ai une table SQL des membres avec différents champs (quoi de plus normal ^^).

J'ajoute un champ "points".

J'aimerais que toutes les X minutes, ce champ s'incrémente de X points.

Le tout sans passer par crons, macros... etc. Car utiliser ce genre de chose me ferait dépendre d'un site externe et l'heure d'exécution n'est pas forcément fiable... bref pas ces bidules =D

Dans un premier temps j'ai pensé à prélever la date de connexion d'un membre; d'attendre sa prochaine connexion pour ensuite faire une soustraction "dernière connexion-temps actuel". Ainsi compter le nombre de minutes écoulées depuis la dernière connexion et ajouter les points qu'il faut.

Mais :
=> Si ca ne se fait qu'au moment de la connexion. Cela signifie que si le membre reste sur le site 5 heures par exemple, il aura beau rafraichir le site, ses points n'augmenteront pas tant qu'il se se sera pas déconnecté puis reconnecté.

=> Autre chose, si j'exécute le prélèvement d'heure, non pas seulement à la connexion, mais sur toutes les pages ma base de donnée risque d'être fortement surchargée...


Bref, auriez-vous une autre piste ?
On dirait que tout celles auxquelles j'ai pensé sont faillibles...

Merci d'avance !

LA GLOBULE

Si vraiment tu ne peux pas utiliser de taches crons et que la mise à jour en "live" n'est pas nécessaire (j'entends par la que ce n'est pas génant si le membre ne "prend" ses points que lorsqu'il se connecte), tu peux mettre en place le système suivante :
- au niveau SQL, un champ 'points et un champ 'date de dernière mise à jour'
- quand le mec se connecte, tu récupères cette date, tu calcules ta différence de temps, tu as ton nombre de points, tu updates (en mettant à jour la date)
- ensuite, reste le problème du mec qui reste logué 8h : tu prends la date de mise à jour que tu stockes en session
- sur toutes les pages (ou toutes les X) que visite cette personne, tu check la différence entre la date en session et la date courante, et si la différence est supérieur à Y (à toi de définir), tu lances un update de point et de date de mise à jour (que tu modifieras aussi en session)

Cela me semble pas trop bourrin. A tester.

raphlight

Ah oui, utiliser les sessions pourrait être une solution pour les points "non en live" =D

Je teste ça ;)

Hum... et par exemple, pour des sites de jeux tels que OGame où les ressources se produisent justement en live comme je voudrai le faire avec mes points : comment peuvent-ils bien procéder ?

Par exemple, on va sur le site, et après une seconde, on actualise et les ressources ont augmentées.

A moins d'utiliser un cron par seconde, ils font à chaque chargement de page des requêtes vers la base sql ?

LA GLOBULE

Surement.

J'en ai aucune idée en fait.

LupusMic

C'est possible qu'ils n'utilisent pas une base de données en direct. L'idée ce serait d'avoir un processus permanent qui fournit les données métier, en gérant le monde persistant.

Et le processus permanent tu peux le faire en PHP... mais ce serait mieux de le faire avec un langage qui fournit le multi-thread (sinon le daemon risquerait de manquer de réactivité.

raphlight

Qu'appelles-tu "processus permanent" ? "multi-thread" ? "daemon" ?

(Je n'ai jamais entendu ces mots là)

Et serait-ce facile à concevoir un processus comme celà ?

LupusMic

Non, ce n'est pas facile. Sinon ça se ferait en PHP (oui, je trolle :p ).

Tu trouveras les concepts du multi-thread et du daemon assez facilement en cherchant le web.

Par processus permanent, je parlais d'un processus qui n'est pas invoqué à la demande, mais qui est tapis dans l'ombre prêt à dévorer tes visiteurs :D

C'est un concept à opposer au fonctionnement du serveur Web. Lorsque une requête HTTP atteint ton serveur Web, ce dernier se dublique. Le processus original continue d'écouter le réseau, tandis que le processus fils va déterminer ce qu'il doit renvoyer comme réponse au client Web. S'il trouve le fichier, il le sert et disparaît. Dans le cas d'un script PHP, il va faire traiter le fichier PHP par le module PHP pour Apache par exemple. PHP aura un contexte d'exécution qui disparaîtra avec le fils qui mourra après avoir envoyé les données traîtées au client.

Comme tu peux le comprendre, toutes ces invocations sont éphémères, le contexte est perdu à chaque fin de script. C'est pour ça qu'on a besoin d'une base de données, des sessions, etc pour conserver des données entre deux requêtes HTTP.

C'est ainsi que fonctionne le Web.

Mais lorsque tu as besoin de gérer un univers persistant, ce fonctionnement peut être handicapant pour conserver la cohérence du monde. C'est pourquoi on peut imaginer un daemon qui parle avec son propre protocole, qui garanti l'atomicité des accès, la validité des actions, etc. Libre au concepteur d'utiliser une base de données comme solution de stockage des données. Le point important du daemon, c'est que tu peux lui faire gérer des timers et donc déclencher des événements telle que la pousse progressive des arbres et compiler les données en temps réel.

Bref, tout dépend de ce que tu exiges comme fiabilité des informations générées par ton application.

Très honnêtement, essaye-toi à un premier jeu en PHP/MySQL qui gère les ressources toutes les 10 ou 20 requêtes. Ce sera un bon début.

raphlight

Merci pour les infos.

Je vais dans un premier temps revoir un peu mon ensemble de scripts afin de lui faire faire un minimum de requêtes vers la base :)