|
cLive ;-) has asked for the wisdom of the Perl Monks concerning the following question:
I'm writing a 'real time' chat system for about 100 users. I've got most of it thought out in my head, but am now having an internal debate about the best way to update the clients (iframe chat embedded in another web page). The two methods I was thinking of were:
- javascript 5 second refresh. If no new messages, return 204 OK http header, if amended, send X last messages; or
- use HTTP Keepalive to pump out the chat in almost real time, closing and refreshing the pages every few minutes.
Has anyone got any thoughts on what the ad/disadvantages of each system would be, or is there an even better route I'm missing here? The application is in house, so client problems are irrelevent.
cLive ;-)
ps - oh, of course, the whole thing will be written in Perl - that's the On Topic aspect of this :) |
Re: OT? Best method for real time chat application
by Errto (Vicar) on Jun 10, 2004 at 02:24 UTC
|
I did something like that once. I used iframes to store the content, but a Java applet to do the communication with the server. I defined Javascript functions to do the DOM manipulation so as to post and retrieve text from the pages in a browser-independent way. I then had a set of calls back and forth between the applet and the Javascript. I know that many people here are allergic to applets, with good reason, and some are allergic to Javascript as well, but frankly I think it's a pretty decent compromise when you need real-time chat. | [reply] |
Re: OT? Best method for real time chat application
by Fletch (Bishop) on Jun 10, 2004 at 01:33 UTC
|
Why not just use Jabber, which is open source, open protocol, and cross platform (not to mention already being written)? Not everything has to be done in a browser . . .
| [reply] |
|
|
True. But I want general users of the intranet to feel a part of the communication that's going on around them. If the chat is in a seperate window, they're less likely to follow discussions. I mean, look what the chat does to this site's sense of community :)
Worth looking into though if I can embed it in a page easily...
cLive ;-)
Update: Looks like Java jabber clients have come a long way since I last looked. Time for a play....
| [reply] |
Re: OT? Best method for real time chat application
by andyf (Pilgrim) on Jun 09, 2004 at 22:11 UTC
|
Reasoning from observation. The Monastry Chatterbox requires
a refresh to update it. Therefore this is the best way :))
Best practical solution imho is a clientside chat applet
launched somehow.
| [reply] |
|
|
Best practical solution imho is a clientside chat applet launched somehow.
You mean like an IRC Client applet? Or a Jabber applet?
That sounds good.
| MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!" | | I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README). | | ** The third rule of perl club is a statement of fact: pod is sexy. |
| [reply] |
Re: OT? Best method for real time chat application
by eclark (Scribe) on Jun 09, 2004 at 22:10 UTC
|
Personally, I would prefer the method that is closest to real time.
| [reply] |
Re: OT? Best method for real time chat application
by Your Mother (Archbishop) on Jun 11, 2004 at 00:40 UTC
|
Unless it's in frames, you're going to have a problem with either approach as a web app. You'd be giving exactly 5 seconds to type a message, unless you do a JavaScript SetInterval/ClearInterval to pause the refresh on mouse activity in the textfield or something. And maybe save the chatfield into a cookie so the user never got hosed by walking away for a minute.
I did a web chat in an iframe (so the parent didn't have to reload) that was strongly based on techniques in Stein's Network book that ran from a daemon. It was like the PM one, reload on "submit/refresh."
POE is good for this stuff too, regardless of environment.
| [reply] |
Re: OT? Best method for real time chat application
by gmpassos (Priest) on Jun 12, 2004 at 07:51 UTC
|
HTTP Keepalive is a resource to get more than one file in the same HTTP connection. Since you are not sending files, you are sending dynamic data, you can't use this resource, since Apache will close the connection after a cgi/mod_perl call, and since your dynamic data doesn't have a defined size, specially for a chat, where you don't know the full size of the data.
I think that what you want to say with HTTP Keepalive (let me know if I'm wrong), is to keep the port oppened sending data to the users for a few minutes. So, each user will create, let's say, a CGI call, and the cgi will work for some minutes sending data, than it closes to not create errors in the browser, and refresh making a new CGI call.
The point is not the real time question, is the number of users that will connect in your server. If you will have 100 users connected with "HTTP Keepalive" (as you say), you will have 100 process of Apache and 100 conections at the same time to the server, what will make your server very slow!
Here I use the 1st option for a chat of 300 peoples based in a mod_perl script (to avoid startup time) and it works very well and is similar to real time. What I do is to have a hidden frame that refresh each 10s and receives the new msgs, and write with javascript the new msgs in the main frame where the user sees the msgs, and don't know or see any page refresh.
To create a streaming chat (your "HTTP Keepalive" option), you can't make it based in a Apache server, or any WEb server, you need to implement your own HTTP server and let it lead with all the users at the same time, in one process. We can see that in the big ISP, that uses a script in some 8080 port, and accept multiple connections to this port, and handles all the users with one process. The problem is that you need to habe full access to the server to can run something like that. Also you will use more bandwidth, since keep a TCP connection alive uses bandwidth, even if no data is sent.
The 3d option is to create an Applet that make the connection to the server and get the msgs and write them with javascript in the main page, or shows everything inside the applet. But use a applet will be useful only if the connection to the chat server is not over HTTP, since make a HTTP call will always send much more headers than chat messages, and you will not make something that can't be done with javascript, and you will not make something better. If you can make a applet make it to connect to some port each 5s where it get and send msgs, and make this over your own protocol, something like a simple IRC protocol will work
Graciliano M. P.
"Creativity is the expression of the liberty".
| [reply] |
Re: OT? Best method for real time chat application
by allyc (Scribe) on Jun 11, 2004 at 10:30 UTC
|
You could go with a Client / Server Solution using some JavaScript.
If you create a main page for your chat window. You can create a layer to contain the chat messages. If you then create a hidden IFrame on the page which will reload every 5 seconds that contains java script statements to update the layer with the latest chat.
You will need to add the messages to some sort of Database at a guess so each client can request all of the messages that it is missing.
I have done a similar thing to emulate Inboxes in an application, so the page updates it's self when new items appear without the user having to reload the page.
If you want more information on how I did this, just let me know!
Hope this helps.
Alistair
| [reply] |
|
|
