2

在这篇文章中，我了解了 XMPP 的用法。这种事情有必要吗，更重要的是，我的主要问题扩展了：是否可以仅使用标准 HTTP 和浏览器技术（如 PHP 和 JS，或 RoR 和 JS 等）有效地构建聊天服务器和客户端？或者，最好还是坚持使用 XMPP 等旧协议，找到一种将它们与我的应用程序集成的方法？

我通过 LiveHTTPHeaders 和 Firebug 研究了CampFire大约 5 分钟，它似乎使用 Ajax 发送一个请求，直到另一个聊天发生时才得到答复。这只是 CampFire 在服务器上打开一个新线程以侦听更新，然后在线程听到更新时返回对请求的响应吗？我注意到他们正在请求一个特定的端口（8043如果我没记错的话），这让我认为他们正在做的事情比我提到的更复杂。此外，请求的 URL 以/tcp/我觉得有趣的开头。

注意：我预计不会有超过 150 个用户同时在所有房间中进行实时聊天。我知道，如果我正在为像 CampFire 这样的聊天服务构建一个托管付费服务，并且有成千上万的并发用户，我应该花时间研究特殊技术，而不是尝试在我的应用程序中以简单的方式重新发明轮子。

此外，如果您打算使用服务器轮询来进行此操作，您会多久亲自轮询一次以最大限度地提高响应而不会猛烈抨击服务器？

4

2 回答 2

4

该技术被广泛称为Comet，据说这是 Ajax 1上的一些有趣的双关语。

XmlHTTPResponse 变体似乎是最流行的。

XHR 版本本身并不是严格的轮询。正如你所说，客户端连接超时时间很长，服务器实际上并没有发送响应，直到有任何东西要发送。发送响应后，它会断开连接并重新连接客户端。他们称之为长轮询，因为客户端正在启动连接，但它与经典轮询的不同之处在于，即使没有任何变化，客户端也不会不断连接请求新内容（即没有“现在有消息吗？没有？如何现在呢？现在呢？”）

这更像是试图保持一个不断断开的连接打开。

是的，它绝对可以使用标准的 Web 技术构建。

1我更愿意将 Ajax 视为强大的希腊战士，而不是清洁产品，所以我对这个双关语非常不满。

于 2010-04-07T05:55:12.567 回答
1

这首先取决于您的网络服务器负载平衡策略。通过无状态介质 (HTTP) 发布数据的 150 个并发用户通过少量脚本（客户端和服务器端）肯定是有效的。请记住，聊天应用程序只是许多客户端 -> 一个服务器策略，非常适合 Web。

于 2010-04-07T06:02:35.520 回答