sockets?

safra

Hi,

I am working on a tool that needs to be able to communicate with a remote server. Like a chat program but actually only the server will send out messages to those people connected. When a message goes out, it should go through a list of all people connected and send the message to those people part of a group that matches the message.

Is this something for TCP sockets or is there a better way to do this? Technically it should be robust enough to deall with millions of connections. Is there a commercial solution out there? Searching google on PHP socket applications has remarkably few results.

Thanks,
Raoul

Krik

Look up websockets its a new technology coming down the pipe with HTML5. And there is a lot of buzz around them. Note that in doing a search for websockets there will be a lot commercial products mixed into the results.

I have been working on determining if websockets are viable with PHP. One issue is that PHP has no multithreading/multiprocessing ability by default which would be needed for anything over a few hundred concurrent connections, +/- depending on your circumstances. However PHP does allow spawning/forking of child processes but I have read that compared to other languages (with multithreading) PHP is a bit of resource hog. I am working on confirming that for myself as what I read could reflect a bias if the writer favored a different language.

Also look up Node.js, Sockek IO, Kaazing, and Pusher. I don't know much about any of those products just seen them as I have been searching around for websocket info.

Weedpacket

PHP does have functional support for [man]sockets[/man].

safra

@, I read about that when searching but unfortunately this will not be webbased. At the moment I am looking into a PHP server and C# .NET standalone client solution (if possible at all regarding PHP server and C# .NET client)

@, yes, my questions are, is this indeed the way to go and are there any professional robust server side solutions available free or for sale?

bradgrafelman

I would question whether PHP is the right tool for the right job. Can you perhaps explain why you chose to write the server application in PHP?

While PHP might be an "easier" language to write it in, I don't know that it would be nearly as efficient as C, C++, C#, etc.

safra

I know, it is a lame excuse but we are on a Linux server and no experience with developing .NET for Linux... And I have some limited experience with sockets and PHP on Linux while building a simple PHP / Flash chat interface. This however must be way more robust.

That's why I am trying to figure out whether we should stick with PHP, sockets etc.? In fact we would be interested in any commercial Linux socket server as long as it will work with our client which will be C# .NET

bradgrafelman

While it's certainly possible to write the app in PHP, I personally would have chosen something like C/C++. It'd be faster, more efficient (e.g. usage of CPU/memory/other resources), less dependent upon other software, and so on.

Whether or not the extent of the differences is negligible or not for your purposes... well that's hard to say based on the given info. Best I can offer is: Try it and find out. 🙂

sneakyimp

I wrote a PHP/Actionscript socket server (q.v. http://flashmog.net) some time ago. It facilitates remote procedure calls over a socket. E.g., you could call a function on the client from the server. The trick is that it uses AMF3 for data serialization to encode the RPC calls and as far as I know there's no readily available AMF3 library for .NET. You might find the PHP code useful to help you along. The license is GPL.

Supporting "millions" of connections would only be possible with many many servers I think. Not 100% certain about that and it would depend on the number of people connecting simultaneously. My reason for thinking so is that a given machine has about 65,000 ports that it can use. When a client connects (say on port 80 for www traffic) then the server allows the connection and then switches each client to some other port so port 80 is free to speak with other folks who are waiting to connect. If my understanding is correct, then a server would be limited to at the outermost 65535 connections at once -- and probably less because the web server and other services would be bound to some of these ports. And this doesn't even take into account performance considerations: e.g. how fast the file system is, the cpu, RAM, etc.

As for whether PHP is suitable, that's a good question. The bottleneck in FlashMOG as far as I can tell is the serialization and deserialization of data structures for transfer across the socket. I did some testing with AMFEXT which was about 10 to 40 times faster (it's written in C) but it's got memory leaks and really doesn't serialize anything correctly. I'm really hoping to update AMFEXT asap but my C chops are weak and understanding the PHP code base is pretty tough.

safra

Thanks, that is very useful info! I have been ooking around further and find some opensource projects, like supersocket, for C#. Didn't find the solution yet that clearly states capabilities, limitations etc...

bradgrafelman

safra;10995177 wrote:
Didn't find the solution yet that clearly states capabilities, limitations etc...

That's probably because both of those qualities are limited by your application or the server's hardware, not the implementation of sockets.

sneakyimp

There's also rtmpd. They talk about streaming and such on the website but I believe it's all about socket connections. I believe it's written in C and is tweaked for really high performance.

If you are looking to understand more about how to manipulate sockets in code and you are familiar with PHP, you might consider taking a look at the FlashMOG server source code. In particlar, the method serve in the FlashMOGServer class which contains the main server loop and the socket connection calls. Sadly my code is probably not very robust as I haven't been able to spend much time on it, but there are lots of comments and I like to think it would be helpful for learning to use sockets. Under ideal circumstances, I would get AMFEXT updated to provide much faster serialization and then implement a multithreaded version of FlashMOG. This would dramatically improve performance. The downside of this performance improvement is that multithreaded apps are really tricky to write. There's a whole new level of complexity.

planetphp

I'd strongly urge you to consider the C/C++/Java route if you want millions of connections.

sneakyimp

planetphp;10995256 wrote:
I'd strongly urge you to consider the C/C++/Java route if you want millions of connections.

I don't think Java provides any advantage over PHP because
1) both Java and PHP run on a virtual machine of sorts
2) Java's compilation to byte code provides no substantive advantage over PHP's compile-on-demand for a daemon process which can run for hours/days/weeks each time it gets launched.

Some actual benchmarking would be most interesting, though.

Servers written in C or C++ are certain to be much faster I think. I wonder how involved/expensive such an undertaking might be? Either using RTMPD or writing a custom socket server in C? I'd wager C/C++ programmers are pricier than PHP/Java devs. If you are really serious, some assembler would really squeeze out serious performance.

In either case, writing daemons and multithreaded processes is trickier than simple scripts that handle page requests so your typical script jockey is probably inadequate. The programs typically run for a very long time and are much less linear. One has to contemplate concurrency and stochastic issues, watch out for memory leaks, etc.

jeepin81

If you don't have the experience w/ C++ why not check out HipHop... especially if speed is the main issue..

https://github.com/facebook/hiphop-php/wiki/

sneakyimp

jeepin81;10995283 wrote:
If you don't have the experience w/ C++ why not check out HipHop... especially if speed is the main issue..

Oooh. Nice. I wonder how HipHop handles converts loosely typed code into the strict typing required by C.

jeepin81

I would have to guess since facebook relies/built it, it must be pretty solid... especially w/ the size of their development team.

sneakyimp

jeepin81;10995288 wrote:
I would have to guess since facebook relies/built it, it must be pretty solid... especially w/ the size of their development team.

I think that's a reasonable assumption, of course every framework/enhancer/tool like this has its dos/don'ts/gotchas. Very interesting for sure though.