我正在Google AppEngine上创建一个Web应用程序，我希望在发生某些事件后尽快通知用户。这个问题类似于说聊天服务器，因为我需要在一个连接上发生一些事情（某人正在聊天室中写信息）传播给其他一些连接（聊天室中的其他人获取该消息）。为了从服务器到客户端获得更快的更新，我计划使用XmlHttpRequest进行长轮询，希望AppEngine不会干扰可能的超时时间。然而，真正的问题是AppEngine上的连接之间的高效通知。如何在Google AppEngine上实现“实时”消息传递？
AppEngine上的这种交叉连接通知是否支持不涉及繁忙等待？我能想到的唯一工具就是使用数据存储（缓慢）或memcache（不可靠），并且它们都不会让我避免忙等待。
注意：我知道AppEngine上的XMPP支持。它是相关的，但我想要一个基于浏览器的解决方案，通过XMPP向用户发送消息不是一种选择。
App Engine上的请求被限制为30秒的执行时间，这使得长时间轮询变得困难。此外，您需要保持较低的平均执行时间，否则您将很快用完实例来执行您的查询 - 如果您的应用程序速度相当快，App Engine将只提供新实例。由于这些原因，对于App Engine，长期投票非常气馁。
但是，如果您准备等待一段时间，则roadmap包含“支持浏览器推送（Comet）通信”，这正是您要查找的内容。
谢谢你，这解释了什么限制，这将使实践中很难做长时间投票。 – SoftMemes 2010-04-18 11:26:41
HTTP连接和数据存储API请求都有一个配额，因此相关的成本，并且如果您在实践中使用长轮询，您将最终很快通过这两个配额进行快速烧制。 – 2010-04-18 18:33:52
App Engine的路线图有Comet支持，否则在实现这一点时会遇到一些困难。
你能详细说明一下吗，现在对AppEngine进行长时间轮询是不可能的，以及AppEngine的“comet支持”是什么意思？ – SoftMemes 2010-04-18 10:30:24
您可以随时使用托管慧星服务，例如WebSync On-Demand。无论您用于托管的服务器类型如何，都可以让您推送活动。
你的意思是“实时”或“预计延迟小”？前者不可能通过互联网来实现，因为你不能在传送消息的时间上放置任何*限制。如果没有别的，那就是反铲效应... – 2010-04-17 22:36:58
我把实时放在引号中，暗示我不希望对从一个连接到另一个连接的通知所花费的时间有严格的实时限制。我真的要求一个尽可能小的延迟解决方案，仍然保持合理的资源需求。 – SoftMemes 2010-04-17 22:52:08