CODEWITHSUNDEEP
chatlivechat
orokusaki
orokusaki

Reputation: 57158

Special technology needed for browser based chat?

On this post, I read about the usage of XMPP. Is this sort of thing necessary, and more importantly, my main question expanded: Can a chat server and client be built efficiently using only standard HTTP and browser technologies (such as PHP and JS, or RoR and JS, etc)? Or, is it best to stick with old protocols like XMPP find a way to integrate them with my application?

I looked into CampFire via LiveHTTPHeaders and Firebug for about 5 minutes, and it appears to use Ajax to send a request which is never answered until another chat happens. Is this just CampFire opening a new thread on the server to listen for an update and then returning a response to the request when the thread hears an update? I noticed that they're requesting on a specific port (8043 if memory serves me) which makes me think that they're doing something more complex than just what I mentioned. Also, the URL requested started with /tcp/ which I found interesting.

Note: I don't expect to ever have more than 150 users live-chatting in all the rooms combined at the same time. I understand that if I was building a hosted pay for chat service like CampFire with thousands of concurrent users, it would behoove me to invest time in researching special technologies vs trying to reinvent the wheel in a simple way in my app.

Also, if you're going to do it with server polling, how often would you personally poll to maximize response without slamming the server?

Upvotes: 2

Views: 664

Answers (2)

Shyam
Shyam

Reputation: 2377

That would first depend on your strategy of your webserver load balancing. 150 concurrent users that publish data over a stateless medium (HTTP) is certainly efficient with the bit of scripting (client- and server side). Remember that chat applications are just many client -> one server strategies, that fits perfectly over the web.

Upvotes: 1

kibibu
kibibu

Reputation: 6184

The technology is broadly called Comet, which is supposedly some hilarious pun on Ajax1.

The XmlHTTPResponse variant seems to be the most popular.

The XHR version isn't strictly polling per se; as you said, the client connects with a long timeout and the server doesn't actually send a response until there is anything to send. Once the response is sent, it drops the connection and the client reconnects. They call it long polling, because the client is initiating the connection, but it differs from classic polling in that the client doesn't constantly connect requesting new content even if nothing has changed (i.e. no "is there a message now? no? how about now? what about now?")

It's more like trying to keep a constantly dropping connection open.

Yes it can absolutely be built using standard web technologies.

1I prefer to think of Ajax as a mighty Greek warrior rather than a cleaning product, so I frown mightily upon this pun.

Upvotes: 4

Related Questions