创建聊天室应用程序的问题 [英] Problem with creating chat room application
问题描述
我正在尝试为某个网站创建一个类似聊天室的应用程序.为此，我有两个选择:
I am trying to create a chatroom like application for some website. For this I am having two options:
使用套接字编程并在服务器上打开一个套接字并将其连接到该聊天室中的所有客户端.对于这个客户端，首先下载聊天室的小程序.
To use socket programming and open a socket at server and connect this to all the clients who are in that chat room. for this client first download the applet of the chat room.
只是以 1 秒的间隔连续向服务器发送 Ajax 请求并刷新页面的聊天内容区域.
just to send requests to server with Ajax continuously with 1 second interval and refreshing the chat content area of page.
我无法决定哪种策略会更好.因此，如果有人告诉我哪种资源占用更少，以及是否还有其他更好的选择，请告诉我.
I can't decide which stretagy will be better. So if anyone tell me which will be less resource intensive and if there is still other better option then please tell me.
其次，我想使用存储在服务器上的会话文件，该文件维护所有登录的用户会话.那么我应该如何访问存储在服务器上的文件，以便我可以拥有一些会话对象的成员变量，如
Secondly I was thinking to use the session file stored on the server which maintain all logged in user's sessions. So how should i access that file stored at the server so that i can have some session object's member variable like
sessionobject.chatroom="1".//请不要去语法，而是要了解它的含义.
sessionobject.chatroom="1". //Please donot go to syntax but on its meaning.
那么是否可以在服务器端访问服务器创建的文件来维护会话呢?如果是，那么如何?
So is it possible to access the file created by the server at the server for maintaining sessions? and if yes then how?
推荐答案
对于客户端，我会看看 Comet，这是向浏览器执行服务器端推送的技术术语.您可以查看多种方法来执行此功能，您提到了其中的两种方法(长套接字和轮询).这两种技术都可以使用 CometD 来执行，这是 Dojo Foundation 使用 Bayeux 规范构建的 JavaScript 库.
For the client-side, I would take a look at Comet, which is the technology term for performing server-side push to a browser. There are a number of methods you can review to perform this functionality, two of them you mentioned (long socket and polling). Both of these techniques can be performed using CometD which is a JavaScript library built by the Dojo Foundation using the Bayeux specification.
至于确定哪种方法更好，您需要查看您的基础架构.许多服务器受到处理线程数的限制，并且在任何时候只能处理一定数量的传入套接字.一旦达到限制，任何其他套接字将排队(或根据服务器丢弃)，直到套接字被释放.Tomcat6 以及其他较新的服务器确实支持使用 NIO API，它允许非阻塞客户端套接字处理，从而消除对传入套接字连接的限制.如果您在客户端和您自己之间有任何具有套接字限制的 Web 服务器、防火墙、代理、负载平衡器等，则需要在最终解决方案中考虑到这一点.如果您的基础设施可以支持这种方法，那么这种方法非常有效，因为它可以为您的客户提供最快的响应时间并降低套接字设置和删除的成本.如上所述的缺点是您的基础架构需要支持您预期的最大用户数(支持包括文件描述符等).
As for determining which approach is better, you need to look at your infrastructure. A lot of servers are limited by the number of processing threads and can only handle a certain number of incoming sockets at any one time. Once you reach the limit, any further sockets will be queued (or dropped depending on server) until sockets have been released. Tomcat6, along with other newer servers do support use of the NIO APIs which allows for non-blocking client socket processing, which removes the restrictions on incoming socket connections. If you have any web server, firewall, proxy, load balancer, etc.. between the client and yourself that has a socket limit, you will need to take that into account in your final solution. This approach works great if your infrastructure can support it as it gives your clients the quickest response time and lowers the cost of socket setup and takedown. The downside as mentioned is that your infrastructure would need to support your maximum number of users expected (support includes file descriptors, etc..).
使用轮询的替代方法:虽然增加了更多的开销并且由于不总是连接而具有更慢的响应时间，但它的好处是允许您的后端潜在地使用更少的资源来支持相同数量的用户(更少的文件描述符，等等...).
The alternative method of using polling: while adding more overhead and has slower response time due to not always being connected, has the benefit of allowing your backend to potentially use less resources to support the same number of users (less file descriptors, etc...).
至于你的第二个问题，我不太确定你在问什么.如果您尝试在该用户生成的请求之外访问用户会话中的信息，则这是规范所不允许的，并且会被视为违反安全性.如果您正在讨论在用户请求期间在用户会话中存储和访问信息，那么使用标准 HttpSession API 是可能的.我建议您不要使用或尝试使用第一种方法，因为它不是一个好的设计.如果您需要维护所有用户线程都可以访问的用户数据，那么您将需要维护单个用户会话(数据库、文件等)外部的数据.
As for your second question, I'm not really sure what you are asking. If you are trying to access information in a user's session outside of a request generated by that user, that is not something allowed by the specification and would be considered a security violation. If you are talking about storing and accessing information in a user's session during a request by that user, then that is possible using the standard HttpSession APIs. I would recommend you do not use or attempt to use the first approach as it is not a good design. If you need to maintain user data that needs to be accessible by all user threads, then you will want to maintain that data external to an individual user's session (database, file, etc..).
希望这会有所帮助.
这篇关于创建聊天室应用程序的问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
