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.
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". //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?
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.
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...).
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..).
Hope this helps.
