Pour tracer la progression, je charge en local les sauvegardes de ma base de données et j'ai un script qui switch entre les sauvegardes pour comparer ce que le joueur possède à différent moment et déterminer si c'est possible ou non.
Sinon pour la solution:
De plus, ca ne ferait que réduire la probabilité que ca ce produise. Même si tu as un très bon serveur, les joueurs risque de te le saturer quand même en spammant.
Comme possible solution je retient:
-Les transactions. Je les utiliserais personnellement sous forme de "mini-transaction". Le select et le delete à la suite.
-En cas de problème, s'arranger pour que la situation soit défavorables aux joueurs. Ca diminue de façon drastique les tentatives, mais par contre vous allez avoir de temps en temps des innocents qui vont se plaindre sur votre forum. (vécu)
-Effectuer les deletes immédiatement aprés le select quand c'est possible (ca rejoin un peu le premier point).
Aprés réflexions, voici la solution que je vais implémenter:
En début de script, avant même la connexion à la BDD, j'instaure un système de vérou via la session.
Le script ressemblera globalement à ca:
Sinon pour la solution:
keke a écrit :Une solution pourrait-elle être d'avoir un serveur de meilleur qualité pour éviter des problèmes de latence ?Ca signifierais que tu sois obligé de baisser la charge maximal de tes serveurs. Tu augmente donc significativement ton ratio Joueurs/Dépense serveur.
De plus, ca ne ferait que réduire la probabilité que ca ce produise. Même si tu as un très bon serveur, les joueurs risque de te le saturer quand même en spammant.
uriak a écrit :Pour ce cas particulier il y a une autre solution : ne pas détruire/créer d'armée, mais l'affecter à une attaque ou à un joueur. Il n'y a plus de "créer" ni de "DELETE" seulement un "UPDATE" qui s'il est appelé 2 fois ne sera pas dramatique. Par contre ça oblige à réviser le schéma SQL derrière...L'idée est bonne, mais comme tu le dis, c'est du boulot, et ce n'est valable qu'ici...
Comme possible solution je retient:
-Les transactions. Je les utiliserais personnellement sous forme de "mini-transaction". Le select et le delete à la suite.
-En cas de problème, s'arranger pour que la situation soit défavorables aux joueurs. Ca diminue de façon drastique les tentatives, mais par contre vous allez avoir de temps en temps des innocents qui vont se plaindre sur votre forum. (vécu)
-Effectuer les deletes immédiatement aprés le select quand c'est possible (ca rejoin un peu le premier point).
Aprés réflexions, voici la solution que je vais implémenter:
En début de script, avant même la connexion à la BDD, j'instaure un système de vérou via la session.
Le script ressemblera globalement à ca:
Code PHP :
<?php
if(isset($_SESSION['anti-spam'][$_SERVER['SCRIPT_NAME']])) //Si on à déjà accéder à cette page.
{
if($_SESSION['anti-spam'][$_SERVER['SCRIPT_NAME']] > time()) //Si le verrou est encore fermé, il s'agit d'un spam
{
echo 'Merci de patienter, traitement en cours.';
$_SESSION['penalite']++;//A chaque spam, je lui met une seconde d'attente en plus.
exit();//On casse l'execution de la page.
}
}
//Si on arrive jusqu'ici, alors le verrou n'est pas fermé. On enregistre la date d'expiration du nouveau verrou, en prenant en compte les éventuels pénalitées.
$_SESSION['anti-spam'][$_SERVER['SCRIPT_NAME']] = time() + 2 + $_SESSION['penalite'];
Vue que la toute premiere chose faite est de mettre le verrou, je pense limiter les accés concurrent aux scripts, de plus je décourage rapidement les joueurs avec des délai d'attente toujours plus long s'il tente de forcer le script. (pénalités)
Je vais y ajouter un système de session unique. Finit les doubles (voir triple) session pour tout péter.
Le principe est simple, chaque session posséde un Identifiant de session, lors de la connexion d'un joueur, j'enregistre l'identifiant de session du joueur dans la base de données.
A chaque page, je vais vérifier que l'identifiant de session correspond toujours a celui inscrit dans la BDD. Si ce n'est pas le cas, je lui affiche un message d'erreur du style "Quelqu'un viens de se connecter sur votre compte.", et je détruit sa session.
Au niveau économie de ressource, je dispose déjà d'une requete faite sur toutes les pages pour vérifier si le joueur a de nouveau message. En pratique, c'est un simple select qui prend le champ 'NbrMessageNonLu' dans la table Membre. J'ai donc juste a ajouter la selection de l'identifiant de session, ce qui n'est pas un problème.
Beaucoup de jeux font des actions récurrentes a chaque page, comme l'affichage du nombre de ressources, je pense que vous pouvez facilement trouver une requête où y greffer l'identifiant de session sans avoir besoin de créer une nouvelle requête.
Je pense qu'avec ces deux script, je bouche la faille sans manger de ressource, qu'en pensez vous?
Désoler pour les postes hyper long, mais j'ai un conseil a vous faire partager:
Lorsque vous bannisez des tricheurs, ne donnez jamais la moindre indication sur le bug. Même si celui-ci est corrigé. Il y a 6 jours environ, en justifiant la raison des bans, j'ai expliqué comment ils ont produit le bug. Le script mis en cause étant désactivé, je me suis pas fait de soucis. Or, depuis que j'ai expliqué le bug, le serveur subit de rude montés en charge jusqu'ici jamais atteintes, alors que le trafic n'as pas changé.
Je vous dirais une fois le système anti-spam si c'est revenu à la normal...