+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Implémentation simple d'une queue d'events Ajax (/showthread.php?tid=5792)
Pages :
1
2
Implémentation simple d'une queue d'events Ajax - niahoo - 03-11-2011
Yop,
Je cherche à faire un truc simple :
Dans l'interface utilisateur d'un jeu web, il est possible de cliquer sur pas mal de choses (ennemi, personnage, objet, carte, etc.) qui vont lancer une commande vers le serveur et en attendre le résultat, ou plus simplement aller pêcher des informations sur le serveur.
Comme le navigateur ne gère que X requêtes en simultané (2 je crois par défaut) et que l'une des deux requêtes sera occupée par du long-polling (mais cet aspect est accessoire), je voudrais pouvoir mettre en file d'attente mes requêtes ajax afin qu'elles soient envoyées une par une.
Quand une requête termine et que l'information revient, alors l'information est traitée via les fonctions success/error et complete mais je souhaite que la requête suivante parte aussitôt sans attendre la fin de ce traitement.
J'ai une idée basique de l'implémentation qui serait simple et fonctionnelle, et d'un autre côté j'ai trouvé quelques frameworks qui le proposent mais avec beaucoup d'autres features dont l'utilité me laisse dubitatif.
Donc, avez vous déjà réalisé une implémentation d'un tel système qui vous satisfasse, ou bien connaissez vous un framework léger qui gère ce processus ?
merci
ah ben je viens d'en trouver une sur le blog d'Anthor que je m'en vais tester !
Mais n'hésitez pas à répondre quand même si vous avez une solution avec une API sympa.
RE: Implémentation simple d'une queue d'events Ajax - Myrina - 04-11-2011
J'ai fait un traitement similaire qui peut te donner une orientation pour une bonne partie de ton problème.
Mon traitement repose sur une utilisation d'un tableau avec dépilement du premier élément. Ce tableau contient la liste des actions que le programme doit réaliser l'une après l'autre. A la fin du chargement de ma page, j'appelle une fonction (charge(serveurs.shift())) en fournissant le premier élément du tableau que j'ai dépilé. Cette fonction réalise l'appel AJAX d'après les informations fournies. A la fin du traitement du retour de l'appel AJAX, si il reste encore des éléments dans le tableau, je rappelle la fonction (charge(serveurs.shift())).
En javascript (et JQuery), cela donne :
var serveurs=new Array(...,...,...);
function charge(serveur) {
.
.
.
$.ajax({
url: "URL",
async : true,
success: function(data) {
if (serveurs.length>0) {
charge(serveurs.shift());
}
.
.
.
}
});
}
Par rapport à ta problématique, il faut, à chaque action, empiler un nouvel élément dans le tableau et effectuer un petit traitement pour exécuter la boucle de chargement si aucun chargement n'est actuellement en cours (peut-être: si le tableau est vide alors il faut démarrer la boucle sinon, procéder simplement à l'empilement)
J'espère que ceci te donneras des pistes pour arriver à tes fins.
RE: Implémentation simple d'une queue d'events Ajax - Argorate - 04-11-2011
Je ne comprends pas bien l'intérêt? si tu lances plusieurs requête ajax, 2 se feront, les autres seront naturellement bloqué et se débloque dès que les celles en cours sont fini (le principe de queue est donc naturellement présent non?)
RE: Implémentation simple d'une queue d'events Ajax - Thêta Tau Tau - 04-11-2011
@argorate : Il me semble qu'au contraire quand tu fais une requête et qu'il y en a déjà en cour, les plus anciennes sont arrêtés au profit des nouvelles, d'où le traitement serveur qui se fait pas ou la réponse qui est pas envoyée etc.
(cela dit je suis nul en AJAX).
RE: Implémentation simple d'une queue d'events Ajax - niahoo - 04-11-2011
@myrina c'est ce que j'étais en train de faire plus ou moins, j'ai également trouvé AjaxQ qui semble pas mal. mais je me suis rendu compte qu'il fallait d'abord le code côté serveur pour que mes tests soient plus simples.
@argorate & Thêta Tau Tau : l'intérêt c'est également de ne pas bloquer le navigateur en laissant de courtes pauses afin que d'autres requêtes puissent partir (celles d'autres onglets par exemple). C'est aussi de pouvoir contrôler l'ordre des requêtes et donc d'avoir une appli au comportement cohérent. Je ne savais pas que les requêtes en cours s'arrêtaient au profit des nouvelles et je pense qu'il faut vérifier parce que ça m'étonnerait, mais si c'est le cas c'est une raison de plus. Ensuite, l'intérêt c'est d'avoir une seule requête en cours pour que le serveur puisse distribuer l'information correctement. Si j'ai 3 requêtes ouvertes par personne, je vais flooder mon serveur et la gestion des réponses sera plus dure qu'avec une seule.
RE: Implémentation simple d'une queue d'events Ajax - Argorate - 05-11-2011
Le truc, c'est que c'est deux requêtes http en même temps, si tu dis qu'une est en permanence utilisé, il t'en reste qu'une, si tu en fait plusieurs en même temps pour un même user, comme on l'a dit, une seul va être traité et les autres stoppées (il faut vérifié le comportement vis à vis de celles en attente) mais dans tout les cas tu flood pas ton serveur puisqu'elles ne sont pas envoyé (ni traité), non?
RE: Implémentation simple d'une queue d'events Ajax - niahoo - 05-11-2011
ben il me semble que firefox, opera et chrome permettent jusqu'à 8 requêtes en simultané. Donc y a moyen de flooder (déjà qu'il va bouffer du long-polling pour chaque connecté) et surtout ça me permet de traiter les demandes dans le bon ordre, éviter les situations dans le style « il reste un point de vie à ton ennemi et 2 à toi, tu tires le premier, il se mange ton projectile, une seconde après tu es mort et il se barre en courant ». Du moins les minimiser mais comme ce sera un jeu lent ça ira.
Ensuite, les queue permettent généralement d'annuler certaines requêtes en attente : par exemple, tu fais 3 modifs sur un bâtiment. À chaque modif une requête est envoyée. Si les requêtes se mettent en queue alors la 3eme qui envoie la dernière config du batiment peut annuler les autres et économiser 2 requêtes donc alléger le traitement. Ça nécéssite quand même que la queue soit assez encombrée pour avoir le temps d'annuler les requêtes précédentes (mais ce ce n'est pas encombré alors ce n'est pas grave pour le client d'envoyer des requêtes en plus).
j'ai pas fini de coder de quoi répondre correctement à ces pollings donc je ne peux pas trop faire de tests pour le moment.
RE: Implémentation simple d'une queue d'events Ajax - niahoo - 17-12-2011
petit up
J'ai créé une boucle qui appelle en permanence la même url afin de disposer d'un push sympa via long-polling.
Ensuite j'ai pris le plugin jQuery 'ajaxq' qui est tout simple et fonctionne à merveille pour mes requêtes ajax afin de n'avoir au maximum que 2 requêtes (comet + ajax normal)
Et ça marche bien à ce qu'on dirait mais pour le moment ma page ne fait pas grand chose.
Je vais probablement utiliser Backbone JS pour mon interface et je suis donc à la recherche d'informations me permettant de mettre dans une même queue les appels de backbone + d'autres appels éventuels. (il me semble que backbone utilise déjà une queue, je n'en suis pas sur mais je pourrai vérifier aisément ce point -- le truc est de savoir si je pourrai incruster des appels ne venant pas be backbone dans cette queue, pas sûr encore d'en avoir vraiment besoin)
J'ai pas encore fait de tests mais je vous dirai si c'est concluant, en attendant si vous avez déjà étudié ce cas je suis preneur d'infos.
Ensuite
RE: Implémentation simple d'une queue d'events Ajax - php_addict - 17-12-2011
il n'y a pas un soucis avec apache et le longpolling?
RE: Implémentation simple d'une queue d'events Ajax - niahoo - 18-12-2011
J'utilise le serveur Yaws ( http://yaws.hyber.org/ ) qui est vraiment adapté à tenir de grandes connexions sur du contenu dynamique.
Effectivement Apache est vite limité en nombre de connexions. Il me semble également avoir lu que c'était encore pire avec des connexions longues.
Il faudra en effet que je fasse des tests mais je suis confiant.