Fausse bonne idée ?

[Max72]

En effet, je vois maintenant les limites de ce système..
Pour les 2 navigateurs simultanément, je n'y avait pas songé et c'est une très grosse faille puisque le joueur peut acheter 2 fois ce qu'il peut acheter normalement (sans compter les points d'action etc).

=> Le recalcul depuis la DB s'impose naturellement avant chaque construction / dépense / ...
Par contre mon cache en session sera conservé à but informatif, et tout sera recontrôlé depuis la BDD avant de faire quoi que ce soit.

En y songeant encore plus, j'imposerai le recalcul depuis la DB si cela n'a pas été fait depuis plus de 15 minutes, histoire que la session reste la plus cohérente possible.

Pour les mesures, je n'en ai fait aucune, mais je vois ça d'un point de vue logique :
10 (voire 20 lorsque le jeu sera plus évolué) requêtes toutes les 2 secondes par joueur, ça me paraît plus lourd qu'un simple accès à un cookie.

Encore une fois, un grand merci, vous m'avez sauvé d'un futur crash.

Le sujet reste ouvert si vous avez d'autres questions ou autres.

____________________
HS : Tu vois Xenos, c'est de cela que je parlais quand je disais que je n'avais aucun recul sur les jeux web

[Prélude]

Mais te voilà avec une bonne expérience à partager

[niahoo]

En y songeant encore plus, j'imposerai le recalcul depuis la DB si cela n'a pas été fait depuis plus de 15 minutes, histoire que la session reste la plus cohérente possible.

Pourquoi ne pas simplement la mettre à jour à chaque fois que tu recalcules tout, c'est à dire à chaque modif ? Au lieu de décider arbitrairement de 15 minutes, tu te contentes de simplement cacher en session tout ce que tu calcules, à chaque fois. Mais ce n'est pas suffisant :

Le problème est que si joueur A modifie le jeu de joueur B (pille ça cité par exemple pour un jeu style travian), il faut aussi que la session de joueur B soit modifiée. Or, comme joueur B n'a pas fait de modif, sa session n'est pas rafraîchie. Et rafraîchir toutes les 15 minutes ne solutionne pas vraiment le problème. Une autre raison pour moi d'oublier ce système de cache pour le moment.

Pour les mesures, je n'en ai fait aucune, mais je vois ça d'un point de vue logique :
10 (voire 20 lorsque le jeu sera plus évolué) requêtes toutes les 2 secondes par joueur,  ça me paraît plus lourd qu'un simple accès à un cookie.

Mais de quelle logique parle-t'on ? est-tu sûr que faire 20 requêtes sur la même machine est plus lent que d'envoyer 3ko de cookie crypté, de le décrypter, de le parser (json_decode) par exemple ? 

Pourquoi chaque joueur devrait envoyer une requête toutes les 2 secondes ? 

[Max72]

Comme dit plus haut, si un joueur A pille un joueur B, alors B reçoit un Event. Dans celui-ci, un paramètre indique si la cité de B doit être recalculée ou pas.
Si oui, lorsque B recevra l’événement (donc rafraichissement ou autre page), sa cité sera recalculée automatiquement, avant que sa demande (construction ou autre) ne soit traitée.
Pour cette partie, je pars serein

Concernant l'autre point, c'est ma logique à moi ^^
De ce que j'ai pu apprendre en PHP, j'ai retenu, peut-être à tort, que l'on devait tant que possible limiter les requêtes à la BDD (avec des jointures, cache etc).
Voilà le pourquoi de tout ce bric à brac ^^

Mais de toute façon, je vais oublier les cookies pour les sessions et revenir à des sessions classiques (mais cryptées tout de même).

[niahoo]

Ok pour les events, j'avais lu un peu vite cette partie.

Oui il faut limiter les requêtes au strict nécessaire, mais ça ne signifie pas qu'il faut les remplacer par quelque chose de plus lourd.

Est-ce que ça vaut vraiment le coup de crypter tes session côté serveur, ou tu parles juste du cookie identifiant de la session ?

[Max72]

Oui je parlais du session ID, mais même ça n'empêchera pas le vol de sessions, alors à quoi bon...
Une idée ?

[niahoo]

Utiliser HTTP devrait protéger la connexion des attaques de type man in the middle. Ton cookie doit être httponly. À ce moment là, je dirais que tu préviens la majorité des attaques.

Sauf deux : une erreur humaine du joueur, tu ne peux rien faire ; une attaque de mecs vraiment très très compétents et là je dirais inutile de se casser le cul, ces types sont plutôt occupés à essayer de pirater la NSA (sauf s'ils y bossent) plutôt que de pirater un jeu amateur.

[Xenos]

Utiliser HTTPS, avec de bons algos derrière (de mémoire, The First 200ms of HTTPs est une bonne vidéo, anglaise, pour comprendre l'intérêt d'HTTPS et s'en servir proprement).

Le vol de session, on ne peut pas vraiment s'en prémunir, du fait de la structure du réseau. Le sessID est une interface entre le client final et le serveur; toute personne sachant en présenter un valide sera considérée comme un client final légitime.

Sinon, on devrait tant que possible limiter les requêtes à la BDD (avec des jointures, cache etc), c'est pas tout à fait exact.
Si on peut faire tenir deux requêtes en une seule, alors oui, il est intéressant de les fusionner (jointure) et donc de limiter le nombre de requêtes. Aussi, une requête même complexe (d'apparence) sera parfois plus rapide qu'un traitement par PHP. Elle sera souvent plus claire, et donc plus facile à relire pour la suite.
De plus, la plupart de nos petits jeux gèrent des BDD très légères et les requêtes sont très rapides: mieux vaut coder propre et claire (mais "lourd" à l'exécution) car notre temps de développement est bien plus couteux que le temps de calcul du serveur. Il est d'ailleurs inutile de se préoccuper d'optimisation si l'expérience utilisateur est déjà bonne (qu'une page réponde en 437ms au lieu de 480ms, on s'en fiche complètement, surtout si ces quelques ms ont nécessité du spaghetti code).

Essentiellement, tu gagneras plus à:
→ Faire des requêtes propres utilisant les bonnes jointures
→ Utiliser proprement les index (cf Use the index Luke qui donne de bons conseils)
→ Bien structurer le code et la BDD pour qu'ils soient clair non pas pour toi, maintenant, mais pour n'importe qui plus tard (considère que, quand tu relieras le projet dans 6 mois, tu seras au même point qu'un nouveau développeur)
→ Favoriser les jointures plutôt que les requêtes multiples

... qu'à faire des bricolages stockant des données critiques du jeu dans un conteneur client (aka, dans un système de stockage de données quelconque sur lequel le client a la main).

Après, il n'est pas exclus de pouvoir construire des structures de données 100% partagées, où rien ne serait en BDD et tout en cookies; mais je ne suis pas certain que ce soit intéressant ici en terme de productivité, ni véritablement réalisable sans être une équipe de 10 ingés à plein temps là-dessus.

[Max72]

Justement, je fais en sorte, malgré ce que vous semblez penser, que le code soit simple à maintenir.

Le code qui met en cookie (maintenant en session, j'en suis revenu ^^ ) les données est très simple. Il se base sur la présence d'une session pour déterminer si oui ou non il doit calculer à partir de la BDD ou de la session.
Et si à un moment je dois recalculer le tout à partir de la BDD pour une raison X, je n'ai qu'à insérer un

Code PHP :

<?php 

CurrTown::Calcul_From_DB() 

[Xenos]

si un joueur A pille un joueur B, alors B reçoit un Event. Dans celui-ci, un paramètre indique si la cité de B doit être recalculée ou pas.
Si oui, lorsque B recevra l’événement (donc rafraichissement ou autre page), sa cité sera recalculée automatiquement, avant que sa demande (construction ou autre) ne soit traitée.

Si A pille B pendant qu'il n'est pas là, puis que C pille B avant qu'il ne revienne, cela se passe comment? B doit être recalculé, mais il n'est pas venu avant que C n'attaque: le pillage de C sera calculé avec les données initiales de B, avant le pillage de A? Ou si A pille B 3 fois de suite?