appengine 上的聊天应用程序
我愿意在 App Engine 上实现一个聊天网站。但我发现App Engine不允许我使用服务器推送。 （因为它会在 30 秒后终止响应）。
那么还有什么方法可以 被利用？轮询会导致不良用户吗 经验？意味着用户将 需要等待一段时间才能 从服务器检索新消息？
理想的民意调查是什么 间隔？
如果您使用非常小的轮询间隔，我的带宽会耗尽吗？我会遇到性能问题吗？
I am willing to implement a chat website on App Engine. But I found that App Engine will not allow me to go with server push. (as it will kill the response after 30 sec).
So whats the other method that can
be used? Will polling cause bad user
experience? Meaning will the user
have to wait for some time to
retrieve new messages from the server?What will be the ideal polling
interval?If you use very small polling intervals, will my bandwidth get exhausted? Will I suffer performance problems?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这是一个很老的问题了，但我一直在寻找类似的答案。我认为
Channel API(http://code.google .com/appengine/docs/java/channel/）更适合该任务。据我了解，XMPP 适合与应用程序交互，但不适合与其他用户交互。 Channel API 通过 HttpRequest 实现推送通知。我刚刚在这里找到了一个聊天室的示例：https://bitbucket.org/keakon/channelchatThis is a quite old question now, but I was looking for a similar answer. I think the
Channel API(http://code.google.com/appengine/docs/java/channel/) is much better suited for the task. For what I understand, XMPP is good to interact with the app, but not with other users. Channel API implement push notifications via HttpRequest. I just found an example of a chat room here: https://bitbucket.org/keakon/channelchat不能只使用 XMPP 而不是网站吗？这将是一个更好的方法。轮询当然不会很好地扩展，也绝对不会提供良好的用户体验。
XMPP 与 appengine
Can't you just use XMPP instead of a website? It would be a much better approach. Polling certainly isn't going to scale very well and will definitely not give a good user experience.
XMPP with appengine
我听说有人通过保持连接（即不发送响应）直到连接断开然后重新建立连接来解决这个问题。不过30秒并不算多。
如果这样做，它仍然会比每 30 秒轮询一次对用户来说更敏感。
关于带宽使用：根据有效负载，“典型”HTTP 请求的范围可以从几百字节到几千字节，尤其是带有 cookie 的请求。
假设平均大小为每 30 秒 5kB（悲观），则每 24 小时总计约为 14 MB。也许您可以通过在 cookie 中设置路径来减小大小，这样就不会为这些连接发送它们。也许您不需要每 30 秒再次发送整个有效负载。
I've heard of people working around that by holding the connection (i.e. sending no response) until it dies then reestablishing it. 30 seconds is not that much though.
If done this way it would still feel more responsive to the user than polling every 30 secs.
About the bandwith usage: Depending on the payload "typical" HTTP requests can range from a few hundred bytes to some kBytes especially with cookies.
With an average size of let's say 5kB (pessimistic) every 30 sec that would sum up to around 14 MB per 24 hrs. Maybe you can cut down the size by setting a path in your cookies so they don't get send for these connections. Maybe you don't need to send the whole payload again every 30 secs.
是的，通道 api 是最好的解决方案，使用 gwt 更好
http://www.dev-articles.com/article/Google-App-Engine-sending-messages-with-XMPP-393002
yeah channel api is the best solution, with gwt is even better
http://www.dev-articles.com/article/Google-App-Engine-sending-messages-with-XMPP-393002