View Full Version : most efficient chat type?

07-12-2011, 06:45 PM
What is the most efficient type of chat to make?

From what I see online most people use a database and limit the number of results they return, but I noticed that some chats, like google and facebook, for some reason are able to load the full chat and get results almost instantly.

How do they do it?

I would love to make a replica of a google chat and just redesign the way it looks. If anyone can help me with the javascript/php part of this, that would be great.


rnd me
07-12-2011, 07:31 PM
php would not be a good back-end choice for many reasons, primarily because active connections cannot talk to eachother without committing data to a DB or flat file.

ideally, you would use node.js or nginx.

node lets the temporary message live in ram as properties of a js object, which all connections can potentially see, eliminating latency and physical access delays like hard-drive seeks and sql server pings.
in order to share in php, all connections both have to ping and update a DB, which is completely inefficient from a physical computing standpoint.

a package for node called socket.io allows abstracted real-time communication between all clients on your server at once. It uses 5 different comet methods, auto detected according to browser capabilities.

with socket.io you can send data instantly to one user or all users with a single line of code.

node.js aside, the easiest one-shot route is "long-polling" with <script src="xxx"> pointing to a delay-response server.

the basic trick is to use sleep (php) or setTimeout (node) to keep the http connection open. once data to be delivered becomes available, you prints the data and close the connection. once the connection closes, the client immediately opens a new one. The client can talk to the server at any time with a parallel request.

on a simple hello world comet example, you could send something like:

update({dt:05234034534, msg: "hello world"});

where update redraws info, and reconnect() opens another long-poll request using a dynamic script tag.

this pattern is 100% cross-browser compatible.
better patterns use webSockets, flashSockets, and "ajax2", but those require special handling on the front and back end. unless you have a great lib like socket.io trying to unify all those differences can be a real PITA.

Node.js will be the fastest way to do it, both in construction time and in terms of performance.
in fact, most node demos are "how to make a chat room".
a modest computer (P4, 2gb ram) running node.js can easily support 5000 concurrent active users/connections, broadcasting to each with <100ms latency; does that sound efficient?

07-12-2011, 09:45 PM
It sounds efficient, but I dont really understand what node.js is even.

If you have a tutorial that you would recommend to make a chat client like this with the ability to have multiple chat rooms using this technology, that would be great!

Old Pedant
07-12-2011, 10:51 PM
I would think that you *COULD* do this using MySQL and its "Memory" database engine. That is, all data is stored in memory.

But, really, browser-based chat will never be as efficient as chat programs that do *NOT* use HTTP protocol.

The problem with HTTP is that it is strictly a one-request, one-response protocol, meaning that each time the requestor (browser) must ask for data from the responder (server). Granted, if you can use thread timeouts in the server (as RndMe suggested) that helps a lot.

But much more efficient is a "push" model, where a socket is opened between (non-browser) client and server and *EITHER* end can send data at any time.

You *can* do this in a browser by using a Java Applet, assuming that the user allows the Java Applet to make what the browser might consider an unsafe connection. When Java Applets were first introduced, chat apps were some of the first things created. Then browser users began to realize the dangers that some Java Applets created and things got somewhat tighter. Still, it can be done today.

But more common is to simply create an executable program that the user must download and run completely outside the browser. It's also somewhat more efficient. But it does mean that now you need executables for different operating systems and CPUs.

If you think about it, games such as Poker are glorified chat rooms. And a single CPU poker server can handle maybe 1000 games, with 9 players each, reasonably easily. All because the messages are being sent completely asynchronously and very very compacted. With all the display work, etc., being done in the "chat" application.

Old Pedant
07-12-2011, 10:57 PM
Ahh...and if you look at node.js, it *can* do just what I said, on the server side. It allows you to use socket-based non-HTTP I/O. So the only "trick" is finding client side software that will also all such I/O. And a Java Applet *could* do that.

Still, I think that a browser-based chat app will not likely be as rich or as efficient as a stand-alone one.

08-01-2011, 11:54 PM
Is there any guide for how to do this?

I would love to do it this way, but I really have no clue how.


08-02-2011, 12:00 AM
there is quite a bit of stuff that comes up if you google

how to build a chat application

hope that helps

08-02-2011, 12:45 AM
I cant find anything on it with node.js....

A link would be great.

Old Pedant
08-02-2011, 01:02 AM
As I said, node.js is just the server side answer. You still need a client-side answer that allows socket I/O. Which probably means a Java applet (or creating an executable...but now you have to create separate executables for Windows, Linux, MacOS, etc.)

Despite what I wrote before, if your chat room will never have more than a dozen or so people in it, you really could do it all browser based, with a fairly simple server side backend (PHP or ASP or ...). And if you use MySQL, the chat table in the DB will stay "hot" in memory, so if you keep it relatively small you could just use the MYISAM engine and it would be fine. Actually, I'd bet you could support 100 to 200 or more chat users on a not-too-powerful system this way. Not efficient, but quick and dirty.

rnd me
08-02-2011, 06:14 AM
As I said, node.js is just the server side answer. You still need a client-side answer that allows socket I/O. Which probably means a Java applet (or creating an executable...but now you have to create separate executable for Windows, Linux, MacOS, etc.)

just add the socket.io package to node using npm.

while a good chat is more complicated than i care to recode (you can find plenty of videos on yahoo or google on how to do node.js chat rooms anyways), i'll show just how easy real-time web programming is using node.js + socket.io.

if you've looked at node.js and it didn't blow you mind, i suggest you look again.

install socket.io, and save the following as bingo.js:

//this is an html file to print to users:
var MYPAGE="<html><head><title>BINGO</title>\
<script src=\"/socket.io/socket.io.js\" ></script></head>\
var socket = io.connect('/');\
socket.on('bingo', function (data) {\
document.body.innerHTML= data+ \"&nbsp;\"+ document.body.innerHTML ; \

//handles HTTP requests:
function manager(req, res){
res.writeHead(200, {"Content-Type": "text/html" });
}//end manager()

//start up the servers:
var http=require('http'),
myServer= http.createServer(manager);
var io = require('socket.io').listen(myServer);

//broadcast a ball every 2 secs via sockets
var num=parseInt(Math.random()*75) +1;
io.sockets.emit('bingo', num); // push to a page's socket event, 'bingo'
}, 2000);


(tested ios,droid,ff,ie7/9,op)

then at the terminal, type "sudo node bingo.js", and browse to the machine's IP/DNS url.

you should see numbers appear on the screen, once per 2 seconds.
open a second browser and watch side-by-side; both should show the same numbers at the same time.
open ie6. notice how it actually works.

note how the html page lives in a variable instead of a file. this eliminates mechanical delays and io lag, letting you pump from ram to tcp/ip at light speed.

socket io uses several techniques to achieve real-time with the server including websockets and flash. but, all the coder needs to do is declare the high-level behavior he wants, no fiddling with inconsistencies...

so, here we can broadcast bingo balls to 1000s of users at once, in old or new browsers, minimal delay between data change and screen change, all from under 10 lines of code!

08-02-2011, 10:22 PM
I think I am going to try Old Pendants solution of using a different engine to sent/recieve data faster.

Thanks for the suggestion rnd me, its just a little out of my league.