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

[Argorate]

Oui j'ai bien une table historique pour mes attaques mais elles contient les données résultant de l'attaque (c'est donc déjà traité)

Comme je l'ai dit, je suis contre ce principe de queue dans ce cas, qui n'apporte que des complications techniques sans gain réel (il y a même risque de perte de perf)

La résolution de mes attaques est bien en temps réel comme je disais, c'est a dire, immédiate: ça lance l'algo d'attaque directement et retourne la réponse de l'attaque (en JSON), avec laquelle je fabrique l'animation correspondante qui s'affiche alors sur la map pour le joueur, donc pas d'histoire de queue encore une fois, c'est de l'instantané.

[niahoo]

Pourquoi n'arrives tu pas à comprendre que ce n'est pas parce que tu utilises une queue que ta requête ne peut pas être symchrone ni paraître instantanée au joueur.

Avec tout le code de lock, vérifications ou autres pour te passer d'une queue que tu vas rajouter, ça va être encore moins instantané.

atra, as-tu testé ton système ? parce que quand tu charges 10 prochaines actions, tu bloques le jeu pour tout le monde avec ta transaction, et ce le temps d'en résoudre 10. AS-tu testé de lancer deux requêtes siùultanées pour voir si ça fonctionnait ?

[Argorate]

Le principe de queue est fait pour les jeux à "ordres". Les jeux où on passe des ordres et qui sont résolu que plus tard ou qui mettent du temps à s’exécuter et où il est nécessaire de conserver l'ordre des taches à exécuter, surtout si celle des autres joueur peuvent être exécuter entre les notre.
Ici ce n'est pas le cas.

Tu appels la page d'attaque.php, ça fait l'attaque (très rapidement), point barre.
Ma solution rajoute un if et le save du changement d'état mais c'est pas grand chose je pense. ^^

[niahoo]

Le principe de queue est fait pour les jeux à "ordres". Les jeux où on passe des ordres et qui sont résolu que plus tard ou qui mettent du temps à s’exécuter et où il est nécessaire de conserver l'ordre des taches à exécuter, surtout si celle des autres joueur peuvent être exécuter entre les notre.

non (oui moi aussi j'argumente tu as vu ?)

Tu appels la page d'attaque.php, ça fait l'attaque (très rapidement), point barre.

Et ensuite je viens faire un topic intitulé « Comment empecher l'acces multiple à une page en meme temps? » parce que mon système ne gère pas ce cas, c'est bien ça ?

[Sephi-Chan]

Quand tu empiles un job dans la queue, il est exécuté des qu'un worker est dispo... Le plus souvent c'est immédiat. Par contre tu es obligé d'envoyer les données en push.

Quoi qu'il en soit, l'approche dont on a parlé plus haut fait l'affaire : elle est simple et fonctionnelle.

[niahoo]

en push obligé si tu utilises php.

[Ter Rowan]

désolé d'intervenir maintenant, mais ça m'éveille des questions :

pourquoi la solution de Sephi (le lock non booléen) n'est pas pertinent ? (je n'ai pas compris la réflexion de Sephi qui semblait dire que ce n'était pas pertinent dans le cas de ce jeu)

@Niahoo pourquoi cette solution de lock est si couteuse ?
En effet perso (mais bon je suis quiche sur bien des sujets techniques) autant je me sens à l'aise pour pondre quelques lignes pour mettre en place le lock (j'ai pas l'impression que c'est compliqué mais je rate quelque chose peut être ) autant queue + push, ça me semble une falaise à gravir, et les mains attachées aux pieds

[Sephi-Chan]

Même sans PHP, dès lors que tu n'effectues pas le job dans la requête HTTP, tu ne peux pas renvoyer les informations utiles dans la réponse (à moins d'attendre l'exécution du job, mais on perd l'une des forces de l'asynchrone).

[atra27]

atra, as-tu testé ton système ? parce que quand tu charges 10 prochaines actions, tu bloques le jeu pour tout le monde avec ta transaction, et ce le temps d'en résoudre 10. AS-tu testé de lancer deux requêtes simultanées pour voir si ça fonctionnait ?

L'idée c'est pas vraiment de résoudre les 10 suivantes, mais plutôt de résoudre un joueur.
(Encore est toujours a cause des contraintes de mon gameplay)

et c'est la l'interet du lock manuel!

User 1 n'a pas d'action a résoudre pour lui, il résous celles de user2. Il locke donc les actions (manuellement, puis pose un verrou mysql sur les données quand il les lit pour résoudre l'action en question).
User 2, qui charge sa page, veut se mettre a jour, sauf que comme les actions sont lockées, le code d'update passe tout droit.
Le code d'affichage, lui, récupère les données dont il a besoin:
-Soit les données sont disponibles il les charges et les affiche...
-Soit les données sont lockées (verrou de la base sur le champ), le système attend que user1 ai fini de résoudre cette action et ai déverrouillé...

Bref dans tous les cas, l'action est effectuée avant l'affichage, peut importe si c'est user2 lui même ou user1 qui le met a jour.
Cela a pour effet de gommer les temps sans MAJ pour les non connectés (qui ne se mettent pas a jour sinon...)

Bon c'est pas aussi clean et optimal qu'un systeme de queue avec sheduling, mais dés que j'ai un dédié, je me code un daemon pour gérer ces résolutions d'actions a la noix!


Pour le cas d'Argorate, vu que les actions sont résolues après le clic directement, il y a que deux solutions:

On calcule -> on envoie (ça marche si c'est vraiment pas long)
On met en queue -> on envoie -> on calcule -> on complète le premier envoi

Pour le reste, les verrous/transactions mysql devraient régler le problème.

[niahoo]

Même sans PHP, dès lors que tu n'effectues pas le job dans la requête HTTP, tu ne peux pas renvoyer les informations utiles dans la réponse (à moins d'attendre l'exécution du job, mais on perd l'une des forces de l'asynchrone).

Et bien justement, Argorate veut attendre l'exécution du job. C'est mois sympa a mon sens aussi mais ça pourrait se justifier dans certains cas, pourquoi pas, et ça reste possible.

@Ter Rowan : je pense que c'est coûteux parce que dans l'exemple d'atra tu as 15 joueurs qui attendent que 1 requête efectue ses actions. En gros, ton serveur web ne peut répondre qu'à une requête en même temps. Voilà pourquoi il doit être mégaGigaPuissant.

@atra: j'ai pas bien pigé : le joueur 3 attaque le joueur 2, manque de bol, le joueur 1 est pile en train de taper sur joueur 2. Donc "le code d'update passe tout droit" et ensuite c'est l'affichage qui va afficher ... rien du tout car l'attaque n'aura pas eu lieu. Donc pareil dans ce cas là, l'update ayant échoué tu vas peut être vouloir attendre qu'on puisse le faire, donc une seule requête à la fois.

C'est clair que quand ton jeu a un état global, c'est à dire la DB dans notre cas, c'est la merde pour mettre ça a jour de façon synchrone,tu dois attendre. Et quand il s'agît d'attendre, PHP est tout moisi : tu peux à la limite ouvrir une socket pour attendre la réponse d'un processus qui te signifie quand ta tâche est terminée, ce qui nécessite un truc qui résout les actions en arrière plan, ou bien faire du polling sur ta base mysql.

Y a un truc que je ne saisis pas bien : les transactions garantissent que tes modifications seront atomiques, comment on fait pour ne donner l'accès en lecture/écriture qu'à un seul thread à la fois et pour que les autres threads qui veulent écrire pendant se temps là soient mis à la queue au lieu de se faire jetter, les obligeant à faire du polling ?