2010-04-17 9 views
3

Je crée une application web sur Google AppEngine où je veux que l'utilisateur soit averti le plus rapidement possible après certains événements. Le problème est similaire à celui d'un serveur de discussion, car j'ai besoin que quelque chose se passe sur une connexion (quelqu'un écrit un message dans une salle de discussion) pour se propager à d'autres connexions (d'autres personnes dans cette salle de discussion reçoivent le message). Pour obtenir rapidement des mises à jour du serveur vers le client, je prévois d'utiliser une interrogation longue avec XmlHttpRequest, en espérant qu'AppEngine n'interférera pas autrement que de restreindre le timeout. Le vrai problème est cependant une notification efficace entre les connexions sur AppEngine.Comment puis-je mettre en place une messagerie "en temps réel" sur Google App Engine?

Existe-t-il une prise en charge de ce type de notification de connexion croisée sur AppEngine qui n'implique pas d'attente en attente? Les seuls outils que je peux penser pour faire ceci est soit en utilisant le stockage de données (lent) ou memcache (peu fiable), et aucun d'entre eux me permettrait d'éviter occupé-attente.

Remarque: Je connais le support XMPP sur AppEngine. C'est lié, mais je veux une solution basée sur un navigateur, l'envoi de messages aux utilisateurs par XMPP n'est pas une option.

+0

Voulez-vous dire "temps réel" ou "délai attendu petit"? Le premier n'est pas possible de réaliser sur Internet, car vous ne pouvez pas * * lié à la quantité de temps pour livrer un message. Si rien d'autre, il y a l'effet Backhoe ... –

+0

Je mets des guillemets en temps réel pour laisser entendre que je ne m'attends pas à de vraies limites en temps réel sur le temps qu'il faut pour recevoir une notification d'une connexion à une autre. Je demande vraiment une solution qui a un délai aussi petit que possible, tout en restant dans les limites des ressources nécessaires. – SoftMemes

Répondre

4

Les requêtes sur App Engine sont limitées à 30 secondes d'exécution, ce qui rend difficile l'interrogation longue. En outre, vous devez maintenir votre temps d'exécution moyen à un niveau bas, sinon vous manquerez rapidement d'instances pour exécuter vos requêtes. App Engine ne provisionnera de nouvelles instances que si votre application est assez rapide. Pour ces raisons, Long Polling est fortement déconseillé sur App Engine.

Si vous êtes prêt à attendre, le roadmap inclut "Prise en charge de la communication par navigateur (Comet)", ce qui correspond exactement à vos besoins.

+0

Merci à vous, cela explique quelles sont les limites qui rendront difficile de faire de longues interrogations dans la pratique. – SoftMemes

+0

Il y a un quota, et donc des coûts associés, à la fois aux connexions HTTP et aux demandes d'API de datastore, et vous finirez par les graver très rapidement si vous utilisez l'interrogation longue en pratique. –

1

La feuille de route App Engine est prise en charge par Comet, sinon vous aurez du mal à y parvenir.

+0

Pouvez-vous élaborer sur exactement ce qui rend impossible de faire de longues interrogations sur AppEngine aujourd'hui, et ce qu'on entend par "comet support" pour AppEngine? – SoftMemes

1

Vous pouvez toujours utiliser un service de comète hébergé, tel que WebSync On-Demand. Cela vous permettra de pousser des événements indépendamment du type de serveur que vous utilisez pour l'hébergement.