tags:

views:

187

answers:

4

I am just getting started in using sockets to communicate to my Flex application as I require fast communication between the client and my server. I had a look at PHP sockets, but as PHP wasn't made to be run on a server in that way (you can, but I get the feeling it is frowned upon) I am not sure whether PHP is the best method of communicating with Flex using sockets.

My application requires the use of fast communication to the server as it will incorporate features such as private chat to other users, and remote control of the flex client from the server.

Should I use PHP sockets in my situation, or should I find an alternate language or even an alternative to sockets? My worry is that I shall start using PHP sockets, but it won't be able to cope under the load. Speed could also be an issue when using PHP.

Edit:

Thanks for the answers, it is much appreciated. As I can gather, PHP is stable when it comes to the use of sockets, but the language was only designed to be used in a request/response environment as Benson said.

Thanks to Cornel, a great alternative for my situation in using Flex with sockets was pointed out as being BlazeDS, using Java instead of PHP.

+4  A: 

Actually it is my experience that PHP5 sockets are quite good. They are written in C and built-in to the PHP5 binary, so they would run quickly, as opposed to being implemented in PHP itself.

Check out nanoweb and nanoserv:

http://nanoweb.si.kz/

http://nanoserv.si.kz/

The author has done an impressive job of putting PHP sockets to work, building a highly capable pure-PHP webserver with nanoweb, and a complete server daemon framework for PHP 5.1+ with nanoserv.

Looking through the nanoserv documentation and code base may give you more confidence in PHP sockets.

Docunext
+3  A: 

PHP will pretty much map down to Linux sockets or similar, so I see no reason why it is a bad idea; as PHP is just a dynamic binding of a C implementation.

Looking at http://svn.php.net/viewvc/php/php-src/trunk/ext/sockets/sockets.c, it seems fairly sane.

Implement, test and benchmark. If it doesn't crash, is fast enough and the constraints are suitable ... go for it.

Aiden Bell
+3  A: 

Defining your own protocol over plain sockets in order to implement messaging and remote communication will take a significant amount of time - even for the basic messaging features. My suggestion is to use a server like BlazeDS if possible, you do not have to reinvent the wheel.

Yes, theoretically your application will perform faster if the protocols are optimized for your particular uses cases, but it will cost you a lot in development time.

Cornel Creanga
Fantastic, BlazeDS looks like a great alternative for my situation. Thanks for pointing that out.
Joel Kennedy
+1  A: 

I also suggest node.js with sockets.io. Though this is best if you want to maintain a open async connection to the server. If you are just doing synchronous req/response calls the I would just use http + php.

Php is really designed to be used in a shared nothing req/response environment. It's not suitable as a real application server. Node.js is a lot better for this but it's JavaScript so best to look into using json for serialization.

If performance is really important (real time gaming) then a binary protocol is best. Depends really what your app does. With node, it json.decode 3k messages/sec on a linux vm on my laptop. Fast enough for all but real time gaming.

Benson Wong