User to User web chat application (PHP) - what choice?

Question

Hi,

I am looking to implement a 1 on 1 user to user web chat application for a new website in the works. Something similar to Omegle is the aim for the final product. Does anyone know of ready made solutions that are capable of this?

Due to my experience, PHP is the language of choice. Omegle was written in Python using the twisted library. Should it come down to building the application from scratch, can anyone give advice on a solution to networking between users via PHP?

Thanks in advance for the help. As you may have picked up, I have not ventured far out of mainstream websites, so although PHP is fine, the connection / networking layer is fairly foreign to me.

Lobe

Long time reader, first time poster

Answer 1

The old traditional way to do it is to serve a page, which contains all the chat messages. The page is refreshed regulary by user's browser. But this way is a bit lame, because it results in flickering, whole page reload and problems with posting.

The other good way to do it is to use Ajax to check for new messages and to post ones.

Googling gives good results: http://www.phpfreechat.net/

Answer 2

You can't "connect different php users together". All of it will go from user1 to server and user2 to server. Then each user's browser must periodically poll for new content. When you say "the connection / networking layer is fairly foreign to me" I get the impression you think you can do this without having the browsers poll the server. You can't. I haven't used phpfreechat but if it has the capability to do different rooms then you might investigate if it is viable by setting up unique rooms for each user pair.

Answer 3

There are a number of solutions based on Jabber with a JS or Flash client. One easy server to install is Openfire and the company that publishes the (open source) server, also has services to help integration onto websites. At previous website I worked at, I installed the server, but had someone write a flash-based client for it (it's problematic, I'd not do it that way again for the client), but the server itself performed flawlessly with sub-second responses.

It had replaced an in-house AJAX-based chat system, but with a fraction of the client base using it, that ajax client was responsible for 72% of the HTTP hits against the website (and without it we did 700K+ hits/day). Going Jabber-based removed those overnight and helped to speed the site. The Jabber system would also be able to be scaled up 10x with very little extra work.