我正在尝试为某些网站创建一个类似聊天室的应用程序。为此，我有两个选择：
使用套接字编程并在服务器上打开一个套接字并将其连接到该聊天室中的所有客户端。对于这个客户端，首先下载聊天室的小程序。
只是用 Ajax 以 1 秒的间隔连续向服务器发送请求并刷新页面的聊天内容区域。
我无法决定哪种策略会更好。因此，如果有人告诉我哪个资源消耗更少，如果还有其他更好的选择，请告诉我。
其次，我正在考虑使用存储在服务器上的会话文件来维护所有登录用户的会话。那么我应该如何访问存储在服务器上的文件，以便我可以拥有一些会话对象的成员变量，例如
sessionobject.chatroom="1". //请不要去语法而是它的含义。
那么是否可以在服务器上访问服务器创建的文件以维护会话？如果是，那怎么办？
对于客户端，我会看一下Comet，它是执行服务器端推送到浏览器的技术术语。您可以查看许多方法来执行此功能，其中您提到了其中两种（长套接字和轮询）。这两种技术都可以使用CometD执行，CometD是 Dojo 基金会使用 Bayeux 规范构建的 JavaScript 库。
至于确定哪种方法更好，您需要查看您的基础架构。很多服务器受到处理线程数的限制，任何时候只能处理一定数量的传入套接字。一旦达到限制，任何进一步的套接字都将排队（或根据服务器丢弃），直到套接字被释放。Tomcat6 和其他较新的服务器确实支持使用 NIO API，它允许非阻塞客户端套接字处理，从而消除了对传入套接字连接的限制。如果您在客户端和您自己之间有任何 Web 服务器、防火墙、代理、负载平衡器等，并且具有套接字限制，您需要在最终解决方案中考虑到这一点。如果您的基础设施可以支持这种方法，它会非常有效，因为它可以为您的客户提供最快的响应时间并降低套接字设置和删除的成本。如上所述的缺点是您的基础架构需要支持您预期的最大用户数（支持包括文件描述符等）。
使用轮询的另一种方法：虽然增加更多开销并且由于不总是连接而具有更慢的响应时间，但它的好处是允许您的后端可能使用更少的资源来支持相同数量的用户（更少的文件描述符等。 .)。
至于你的第二个问题，我不确定你在问什么。如果您试图在用户生成的请求之外访问用户会话中的信息，则规范不允许这样做，并且将被视为安全违规。如果您正在讨论在用户请求期间存储和访问用户会话中的信息，那么可以使用标准 HttpSession API。我建议您不要使用或尝试使用第一种方法，因为它不是一个好的设计。如果您需要维护所有用户线程都可以访问的用户数据，那么您将希望在单个用户会话（数据库、文件等）之外维护该数据。
希望这可以帮助。