Is PHP socket a viable option for making PHP jQuery based chat?

Question

Hello all,

I am developing a chat module for drupal. I plan to provide multiple backends for chat message processing. I initially started with AJAX and have now included long polling technique in it. Then I came across ape(ajax push engine) and it looks promising. But it will require server side installation of ape for the chat module to work. Although I will also include this as one of the backends for the chat, my main focus is to find a solution which can handle acceptable number of simultaneous chat connections WITHOUT making any server side modifications so that people can use it easily.

I was surfing on net and came across PHP Socket programming and it looks like a viable option.

• If I write a php based chat server, will I be able to maintain a connection which can send data in both directions(from server to client and vice versa) by only using jQuery(along with ActionScript)? Obviously I won't use AJAX on client side.
• Also how many connections will the server be able to handle simultaneously if I write an efficient php socket based chat script and say I dedicate 50MB of RAM to it?
• Will the people on shared hosting will be able to run the php based server side code because they don't have shell access, like we have an option to run cron?
• Also I have read somewhere php is not multi-threaded language so you shouldn't use socket at all. Is this true?
• Is there some other approach which I can use and will be more efficient than this without making any server side modification?

Answer 1

check this tutorial..... this help you to make a web based chat application using jquery http://net.tutsplus.com/tutorials/javascript-ajax/how-to-create-a-simple-web-based-chat-application/

you can have have their source code and try your self and learn......

Answer 2

What you should think about: Every new connection will block a PHP process. So, if you establish a socket connection to somewhere and let it open for long time the PHP process will be blocked, it cannot accept another connection. So, if you had 50 PHP processes, 50 connections may be established at one time.

This is why I personally prefer using Node.JS for comet applications like chat...

Answer 3

Is PHP socket a viable option for making PHP jQuery based chat? - No :)

And given your constraints of a shared host and circa 50mb of RAM I'd suggest PHP really isn't an option either.

In reality, HTTP isn't really ideal for this kind of thing, HTTP is a stateless request/response based protocol, and what you need is a stateful persistent protocol such as XMPP.

You can 'hack' it using web technologies, as you have already done with long poll and ajax, which is technically the only way to do it over HTTP, all other variants of HTTP chat are always either continuous timed poll, or long poll, these are the only way to do it with a client server http setup.

You can do this in a 'lighter' way by using a tech such as node.js (See the node.js chat demo) this is lighter on resources server side, but kind of knocks your shared host requirement.

Or, you can do this with techs made for the job, which would be using an XMPP/Jabber server at the backend and a flash/flex based XMPP client on the front end - this easily supports 5000+ connections per backend server, but again is killed by the shared host requirement.

In the long, long, long term the answer web architecture answer is to have HTTP Server, Cache and Client on all devices, this would make each device a node in a P2P network and all us to do anything, but that's a long way off yet :)

Hope that helps!

Answer 4

PHP is not well-suited to this kind of problem, at all. You can write a daemon that uses the pctnl functions to fork a new process on each connection (up to some configured # active processes), but it's going to chew up memory because you're forking a new process for each connection. Given your requirements, I'd look somewhere else.

You seem to want to have this stuff hostable on shared web hosting, and while I can sort of see why, you ought to at least recognize that you're not really hosting a web application, you're hosting a chat application (that perhaps has a web-based UI).