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

[php_addict]

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 ?

http://dev.mysql.com/doc/refman/5.0/fr/i...ation.html

[Argorate]

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.

Non, justement, je ne veux pas attendre! je veux juste empêcher qu'il y en ait plusieurs, c'est pas pareil.

@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.

Bon, donc là j'ai enfin compris pourquoi tu ne comprenais pas, c'est que tu n'as pas saisie la manœuvre mise en place je pense ^^

Je ne lock pas mon serveur !

je lock une page ET pour 1 joueur qui a déjà une requête sur cette page en cours d'exe

ce qui ce passe c'est que:

si j'ai 15 joueurs, les 15 lancent leurs attaques, il n'y aura absolument aucun problème, elles se feront toutes et dans l'ordre où elles sont demandé.

Le cas qui pose problème pour moi, c'est quand le même mec demande deux fois en même temps - ou presque - la page d'attaque: c'est la que mon lock manuel intervient:

En gros, j'ai rajouter en haut de ma page d'attaque :

if(!$current_joueur->attack_lock)

{

$current_joueur->attack_lock=true;



//... faire l'attaque...



$current_joueur->attack_lock = false;

}

ce qui fait que lors de la deuxième requête du même gars sera bloqué, mais absolument pas celle des 14 autres joueurs, ni même la première attaque lancer par le joueur!! Tu comprends?

Donc là où tu dis : "En gros, ton serveur web ne peut répondre qu'à une requête en même temps.", c'est plutôt : "ton serveur web ne peut répondre qu'à une requête en même temps sur la page d'attaque, pour UN joueur donnée.", ce qui n'est pas du tout pareil, tu me le concèdera.


Ter Rowan : outre le fait que la solution de sephi fait créer une table juste pour ça (et qui en plus demande donc une requête supplémentaire à chaque attaque, alors que si c'est un champs dans tes joueurs, tu l'as chope en même temps que ton objet), en mon cas ça ne peut pas marcher, car les attaques se font par rapport aux coordonnées et pas par rapport au id des joueurs, c'est spécifique a mon jeu a cause de l'histoire de camouflage (faudrait que tu reviennes jouer pour comprendre ^^)

[niahoo]

Oui non mais j'avais pigé ça, mais si tes 14 joueurs attaquent le quinzième une seule fois et en même temps, il va se retrouver avec un nombre de points de vie sacrément négatif, non ?

Edit pour en dessous : ton systeme est malin, mais si un joueur est attaqué, alors tous ceux qui veulent l'attaquer vont devoir recharger la page pour avoir la bonne url d'attaque. on peut mettre un petit script ajax qui fait le boulot (met a jour l'url) discrètement aussi.

[Sephi-Chan]

Pourquoi tu mets pas en place le truc du lock ?

[Argorate]

Si y en a 14 sur le même, en toute franchise j'ai pas testé, mais il faudrait que la rafale qui tue sois émise quasi en même temps (a quel microseconde prêt) qu'une autre d'un autre joueur, pour que ça embête oui...
Dans ce cas, il faudrait lock l'attaque sur le joueur ciblé plutôt que le joueur attaquant? Mais j'ai peur que ça produise des lags et des frustrations lorsqu'une team se coordonne. Si un tir sur deux ils reçoivent un message disant "attaque déjà en cours sur ce personnage, veuillez réessayer", c'est un peu lourd...

Sinon, je n'ai pas comprit l'histoire de l'url d'attaque? pourquoi ça devrait changer?
Pour attaquer, tu double click sur la case où y a la cible, y a pas besoin de recharger l'url pour ça. J'ai pas compris ce que tu voulais dire, sry. ^^

sephi: c'est ce que j'ai fais, c'est pas comme tu l'imaginais?

[niahoo]

Je parlais du système proposé par sephi pour l'histoire d'URL.

Bon et sinon tu vas fabriquer tout un système qui ne va pas gérer les attaques coordonnées ou qui va renvoyer une page d'erreur 9 fois sur 10 pendant les batailles. Vaut mieux encore y réfléchir avant de coder.

[Argorate]

Non mais c'est déjà en place en fait, et ça fonctionne maintenant que tout les cas sont gérer.
Les jeux auquel je jouais y a 10ans (suis tournait sur des serveurs bien moins puissant et plus de personnage sur la map), n'avait pas de soucis, donc je ne m'en fait absolument pas

Le fait qu'il y ait plusieurs attaques en simultané fonctionne parfaitement et ne renvoi jamais de page d'erreur, je ne sais pas d'où tu tiens ça ^^

[Sephi-Chan]

Oui mais c'est important de te dire que l'architecture est quelque chose d'important et que de raisonner avec des outils sérieux (les queues, par exemple) n'est jamais inutile.

[srm]

Ca va être marrant ton système quand tu auras 100 joueurs, 1000 et plus encore :')
Les systèmes de lock sont à fuir comme la peste un peu comme le goto :')

[niahoo]

Non mais c'est déjà en place en fait, et ça fonctionne maintenant que tout les cas sont gérer.
Les jeux auquel je jouais y a 10ans (suis tournait sur des serveurs bien moins puissant et plus de personnage sur la map), n'avait pas de soucis, donc je ne m'en fait absolument pas

Le fait qu'il y ait plusieurs attaques en simultané fonctionne parfaitement et ne renvoi jamais de page d'erreur, je ne sais pas d'où tu tiens ça ^^

Ben c'est toi qui disais qu'ils pouvaient avoir une page d'erreur une fois sur deux. et si tout le monde fait pile en même temps j'ai imaginé qua ça ferait 9/10.

Bon après effectivement c'est très rare d'avoir 15 requêtes pile en même temps. pour le moment, mais imagine toi comme dit oxman que tu as 1000 joueurs, tu peux en avoir des batailles à 20 contre 20 qui cliquent comme des furieux.