我正在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