简短的任务描述:我希望一个登录用户能够发送即时短纯文本消息给另一个登录用户。该解决方案需要易于扩展，并且在带宽和服务器负载(和$$)方面不太需要资源。
第一个想法是做客户端轮询，但这个想法很快就被放弃了，因为它不满足可伸缩性需求。所以，在那之后，我开始研究，并遇到了一些概念，包括套接字，node.js, xmpp。信息量太大了，所以我希望能得到一些建议，为我指明正确的方向。希望有现成的托管解决方案。
@epascarello:感谢您的快速回复。我说了，但没有详细说。在深入研究任何技术之前，我想知道这实际上是我需要的。
大多数的例子集中在即时聊天，但我的要求有些不同。我不需要每个登录的用户都能看到消息，而只需要一个特定的用户看到消息，而可能有100,000个用户登录…
@Saeed Neamati:谢谢!是的，我非常理解这两个客户机-服务器通信选项，并得出结论，即不允许进行拉拔。我现在试图找到的是最具可扩展性(这是主要的先决条件)和(希望)易于实现的推送选项。例如，套接字选项相对简单，但由于服务器过载(或者我错了)，它似乎不会很好地扩展。node.js(至少通过概念描述)应该在这方面做得更好，但我想对这个假设进行一些确认。使用xmpp -我甚至不确定它与我的任务有多相关，以及如何处理它。
@andyuk:安迪，谢谢，是的，插座。io也是我在做研究的时候偶然发现的。据我所知，它需要一个服务器模块，需要在主机上运行。你知道是否可以在任何服务器上运行，或者我需要寻找一个专门的托管公司吗?套接字。
你看过nodejs聊天的源代码了吗?
您只有两个客户机-服务器通信选项。要么客户端发起请求(web上的HTTP请求)，这被称为拉模型(就像客户端将请求从服务器中拉出)，服务器响应它，要么服务器直接发起响应，而不接收任何请求(web上的HTTP响应)，这被称为推模型(就像服务器将数据推出到客户端)。
你所描述的轮询实际上是拉模型，它确实从服务器占用了大量资源。
但是另一方面，当你想使用推送模型时，你的服务器应该知道客户端。换句话说，我们知道HTTP(基于TCP/IP)是一种无状态协议，这意味着在每次请求之后，您的连接将关闭，服务器将失去您并忘记您。
如果您希望服务器知道客户端，您应该保持连接打开。这通常是通过一些HTTP头如Keep-Alive和Connection来完成的。
但是要做到这一点，你应该阅读Comet Programming。然而，这降低了您的可伸缩性，因为在连接和客户端之间保持一对一映射的更多连接是打开的(为了更好地理解这一点，您可以将连接视为服务器的门)。你作为客户占用的时间越多，其他客户可以使用的时间就越少。
结帐socket.io。如果浏览器不支持web套接字，它将退回到次优传输技术。
源代码中甚至包含了一个聊天示例。
至于你对可扩展性的担忧，node.js是完美的，因为它是事件驱动的，非阻塞的性质。处理许多打开的连接是Node的真正优势之一。
Plurk使用Node.js作为他们的实时聊天功能，他们支持10万+用户。