Comment empecher l'acces multiple à une page en meme temps?

[Sephi-Chan]

Ce sont des actions immédiates.

[php_addict]

Ce sont des actions immédiates.

rien n'empêche de les stocker quelque part ne serait ce que pour archiver les actions des joueurs

[atra27]

J'ai déjà réfléchis a ce genre de problème donc jvais partager la solution a laquelle j'ai pensé...

Je sais pas comment tu gère mais pour moi mes attaques sont des actions
Je les stocke donc dans une table action

Pour chaque action, j'avais pensé implémenter une colonne lock.
Ainsi, pour résoudre:

On récupère les actions a effectuer (celles du joueur en priorité, puis d'autres sinon)
On lock les actions (avec un id unique au script)
Une boucle s'occupe d'appeler la résolution sur toutes ces actions
On dé-lock les actions de ce script (grace a l'id unique)
On s'occupe du reste...

Actuellement avec des actions simples, je plafonne a +/- 0.0145 au niveau de la boucle (donc il s'écoule 0.0145 sec max entre le moment ou on est sur qu'une action existe, et le moment ou l'action est résolue et retirée de la liste)
Au vu de ces chiffres, le risque de résolution concourantes est minime, je n'ai donc pas implémenté le système de lock décrit plus haut, je n'ai donc aucun retour sur ma méthode.

M'enfin bon, en attendant mieux, c'est l'idée que je me fait du probléme et de sa résolution...
C'est moins fiable que du vrai queuing, mais c'est plus flexible a mon gout... et puis j'ai pas de dédié sous la main non plus!

[php_addict]

tant qu'à "locker" des tables MySQL autant utiliser les verrous SQL et les différents niveaux d'isolation des transactions

après je ne sais pas si les verrous sont dispos sur un mutualisé...

[Sephi-Chan]

Marrant ce qu'on est amené à faire quand on a des outils de merde. :p

[atra27]

non car mes locks me servent a autre chose...

Par exemple, pour mon debug, ma fonction pour supprimer une action (appelée quand elle est effectuée) ne suprime pas l'enregistrement mais ajoute 1 au lock (via UPDATE lock=lock+1)

Ainsi, comme lock != 0, on ne liste pas cette action, mais elle est toujours en base!
Ensuite, cela me permet de détecter les MAJ concourantes (lock > 1) et donc, de repérer, d'identifier le probléme (via les infos associées a l'action) et d'appliquer la correction plus haut.

De la même façon, je peut très bien vouloir locker une action pour une raison X, mon système me permet de le faire très facilement.

C'est pas plus haut dans ce sujet que j'ai lu qu'il valait mieux attendre de rencontrer les problèmes avant de chercher une solution plutôt que de chercher des solutions a des problèmes qui n'apparaitrons surement jamais?
Personnellement je suis d'accord avec cette approche tant qu'on se donne les moyens de détecter le probléme qu'on a imaginé! (surtout qu'avec un problème de ce genre, on peut se retrouver a chercher des heures! alors que la un simple SELECT WHERE lock > 1 et on sait si ça vient de la ou pas!)

[php_addict]

Marrant ce qu'on est amené à faire quand on a des outils de merde. :p

alors là je te trouve particulièrement élitiste, car avoir un serveur dédié nécessite du temps pour le configurer le gérer, le maintenir et du temps pour apprendre à le maitriser. Et cela nécessite un budget modeste certes mais budget quand même...tout le monde n'a pas forcement le temps, les capacité, et le budget...

ceci dit je suis plutôt d'accord avec toi sauf pour ce qui peut paraitre comme désagréable dans le ton de tes propos. Mais effectivement qui dit web game dit serveur dédié...après il y a de solutions alternatives, je pense à http://www.nainwak.org/ sans réellement connaitre leurs services rendus aux jeux amateurs..

[Sephi-Chan]

La partie crue n'est qu'une plaisanterie…

[niahoo]

Avec erlang je règle le problème en 20 minutes et encore je suis large. Je viens de me prendre la tête 10 minutes pour imaginer une queue avec des accès concurrents en PHP synchrone sur du mutu avec une queue dans mysql, ça me semble faisable mais terriblement balourd à faire.

Il te faut, lors d'une attaque, empiler ton attaque sur ta pile, et attendre qu'elle soit résolue, donc attendre que les trucs empilés avant soient résolus aussi. C'est là que c'est galère car PHP ne peut faire que du polling avec un SELECT pour voir si l'action a été effectuée pour ensuite afficher le résultat. Mais qu'est-ce qui va résoudre l'action ? PHP peut attendre que son action ait atteint la fin de la pile : c'est à son tour. Il va donc lui-même résoudre l'action : ta queue peut donc ne contenir qu'un simple numéro d'attente comme à la poissonnerie à Leclerc. Une fois que c'est à son tour il résout l'action.

ça peut marcher mais c'est moche, pis t'as intérêt a avoir un serveur pas trop bas de gamme et a activer ingore_user_abort

La queue ne doit pas permettre les accès concurrents : quand c'est à son tour, php doit pouvoir être le seul à agir sur le système, donc tout le reste patiente, ça va être très lent.

quelqu'un a une meilleure idée, à part utiliser erlang ?

[atra27]

Évidement il faut activer ignore_user_abort, ou utiliser des transactions (bien mieux)

Mais sinon c'est simple:
Perso, j'ai une table de ce type:

Code :

actions (
  `id` int(10) auto_increment
  `joueur` int(10)
  `start` DATETIME
  `duration` DATETIME
  `type` int(2)
  `data` text
  `linkaction` int(10)
  `lock_nb` int(1)
  PRIMARY KEY  (`id`)
  KEY `joueur` (`joueur`)
)

A chaque page, je résout les actions du joueur courant (WHERE joueur = X AND start+duration < NOW() AND lock_nb == 0)

Si le tableau d'action est vide je charge une dizaine d'actions dans les prochaines a résoudre.

Une fois les actions résolues, je les lock (ou delete)

Pour le gameplay de mon jeu, je suis obligé de tenir un tableau associatif avec comme premier id, l'id du joueur, comme second le type de la dernière action, et comme 3éme l'heure de la dernière action.
Ceci car un même joueur ne peut effectuer qu'une action de chaque type a la fois, bien que plusieurs peuvent êtres programmées a la suite.
C'est plus rapide que de prendre une action, la résoudre, définir la valeur start de la suivante du même type, reprendre la suivante, etc etc.

Bref comme quoi avec un peu de logique, on s'en sort pas si mal...
Enfin j’attends d'avoir un truc jouable pour tester dans le feu de l'action!