Efficacité de la bande passante d’interrogation sur le chat Ajax

J’ai écrit une petite application Web qui est essentiellement un client de discussion alimenté par JQuery dans le navigateur. Pour obtenir les messages que je interroge le serveur avec une demande AJAX, puis en ajoutant de nouvelles réponses, je crains que cela ne soit aussi efficace. autant que possible sans perdre la sensation en temps réel.

http://darklightweb.co.uk/RealTime/

Je ne vois pas comment les interruptions sont possibles, alors je scrute une page toutes les 5 secondes qui ne renvoie rien si aucun nouveau message n’est disponible pour limiter le transfert de données s’il est inactif, s’il contient un message, le message le plus haut dans la liste. La queue est envoyée et je vérifie à nouveau dès que la demande Ajax est terminée jusqu’à ce que la queue des messages soit vide.

D’autres astuces pour rendre cette bande passante aussi faible que possible ou d’autres implémentations possibles?

Les sondages ne sont peut-être pas la meilleure solution pour implémenter une discussion en ligne. Je vous suggère de jeter un coup d’œil à l’implémentation de COMET effectuée par JQuery, qui conserve une connexion ouverte au client, repousse les mises à jour du serveur et est assez évolutive .

Je pense que vous pouvez utiliser une application de chat

Ajax inverse

Reverse Ajax fait référence à un modèle de conception Ajax qui utilise des connexions HTTP à longue durée de vie pour permettre une communication à faible latence entre un serveur Web et un navigateur. Fondamentalement, il s’agit d’un moyen d’envoyer des données d’un client à un serveur et d’un mécanisme permettant de renvoyer les données du serveur au navigateur. 1

Cette communication serveur-client prend l’une des deux formes suivantes:
* Client polling, the client repetitively queries (polls) the 
serveur et attend une réponse. * Serveur poussant, une connexion entre un serveur et un client est maintenue ouverte, le serveur envoie des données lorsqu’elles sont disponibles.

Reverse Ajax décrit la mise en œuvre de l’un ou l’autre de ces modèles, ou une combinaison des deux. Le modèle de conception est également connu sous les noms Ajax Push, Full Duplex Ajax et Streaming Ajax.

moo-comet

Request.Comet est une simple classe javascript permettant de créer facilement des applications multi-navigateurs Comet (Reverse Ajax). Il fournit des transferts de données en temps réel entre le client et le serveur et peut être utilisé avec n’importe quel langage côté serveur.

J’ai écrit presque EXACTEMENT la même application pour faciliter la communication entre amis au travail lorsque divers employeurs utilisent un filtrage Web draconien.

J’ai constaté que la quantité de données transférées pour ces demandes d’interrogation est minime et approche rarement 1 Ko / s par utilisateur connecté, généralement beaucoup moins puisque vous n’interrogez que 5 secondes.

La bande passante est-elle vraiment un problème ou optimisez-vous prématurément?

Si vous décidez de ne pas suivre l’approche COMET, je ferai la même chose que vous, sauf que si la queue contient plusieurs messages, ils sont envoyés tous en même temps. De cette façon, vous n’interrogez que toutes les 5 secondes et pas plus (et pas moins). Bien sûr, avec 100 personnes connectées, cela entraîne toujours 20 requêtes par seconde. Vous devez donc essayer d’optimiser le côté serveur de telle sorte que chaque requête utilise le moins de ressources du serveur (CPU / RAM / temps) possible. La mise en cache est votre ami ici.

Cependant, je ne m’inquiéterais pas de la bande passante car les messages de discussion sont généralement très courts et vos demandes seraient minuscules de toute façon.

Pour accompagner la réponse de msparer, voici un article de blog sur les débits de messages Comet et l’parsing comparative d’une telle technique pour une application de discussion en ligne:

http://cometdaily.com/2008/10/30/comet-apps-will-not-scale-equally/