06-03-2012, 10:19 PM
(06-03-2012, 08:30 PM)Sephi-Chan a écrit : 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 ?