Ratchet: PHP Websocket server

[Jackolantern]

I came across Ratchet the other day, which is a PHP Websocket server. For some people working on games and websites here who feel most comfortable with PHP, this could be a good alternative to going 100% Node.js and Socket.io if you only have minimal "server push" needs. Since it isn't asynchronous or threaded, the coding is quite simple, but that does come with some cons. The server max load is obviously going to be lower than an async or threaded solution, so that may prohibit writing full MMORPGs in it, but the performance does seem decent from the scant performance results reported. It could, however, be just the solution for PBBGs that just need a touch of real-time here and there, such as for chat and PvP notifications.

[Chris]

Lol, funny it's called WAMP.

[Jackolantern]

Lol, funny it's called WAMP.

Yeah, I saw that haha. Acronym fail.

[Jackolantern]

The reason why pretty much all socket stuff, including websockets, is done through the command line is because web hosts do not allow socket programming in PHP (they don't in many other languages as well, since they can be a security risk to let your hostees just socket as desired). They also work on a different mechanic than the typical page-centric PHP model. So yes, you need at the very least a VPS (virtual private server) host account to use these, because you need access to the command line and other OS functionality that you don't get with a web host. It is the same with basically all socket servers, where you need an "application host" besides the regular web host.

The value in websockets over AJAX is that websockets are two-way, while AJAX is one way without what amounts to hacks ("Comet"). Websockets are initiated with a fairly regular HTTP request from the client to the server, they "handshake" and then the connection is upgraded (technically it is a downgrade, but who's counting lol?) to a TCP socket connection. At this point, the connection remains open until either side manually closes it. The server can send data at any time to the browser, and the browser can send data at any time to the server.

This is very different than AJAX. With AJAX, the browser makes an HTTP request to the server, which then responds. It isn't much different from a standard page request, except it can be done with Javascript on the page instead of requiring a new page load. It is so much like a regular page request that you even have to select which HTTP verb to use, such as Get or Post. The connection only lasts for a moment; just long enough to send the request from the browser to the server and get a response. So continuous AJAX requests have the overhead of repeatedly opening and closing HTTP requests, which are already kind of heavy. AJAX has a speed limit, and it is fairly common to have about 1 second or more for a round-trip, while websockets can complete a round trip nearly equal to the latency of the network (the fastest anything can travel on the network), so more in the ballpark of 30ms - 100ms or 10 - 30x faster with 1/5th or less of the bandwidth due to not needing the HTTP headers.

But the biggest issue is that the server cannot send unrequested data to the client with AJAX. That is huge with online games, since much of the communications are server-originated. But websockets will not replace AJAX, nor is it designed to be a replacement. Websocket server implementations are many times more complicated than AJAX (which simply resembles web pages). If you need a ton of data being sent unrequested from the server, aka "server push", websockets could be a good option. If you just need to update a few things when the user performs an action, AJAX is likely the better, easier choice.

[a_bertrand]

If you need fast map updates, then websockets are the best choice. Yet, if you mix PHP and a good websocket implementation then you need to do quiet a mess to make all work correctly together. I just did it today to install node.js on my server with apache + php and MySQL. To make it work I had to install a "proxy" on front of apache.

However, after the initial pain of the installation, and the time to learn how to code the server and client part using socket.io, I can assure you that you will never reach such communication speed with just plain ajax. BTW socket.io fallback to other technologies automatically in case websockets are not available. So far I didn't found anything even remotely at the same level.

[Jackolantern]

The only thing that may end up being at the same level as Socket.io could be SignalR for .NET, which is essentially Socket.io for the .NET world. It has the about the same list of features: asynchronous model, websockets as priority, but with multiple fallbacks to support back to IE6, etc. It is a little bit better organized from an architectural standpoint (.NET async works more like Promises rather than endless callback chaining), but Socket.io still boasts a better chain of fallback solutions (I don't think SignalR has a Flash bridge fallback).

[Jackolantern]

Socket.io automatically falls back to several Comet technologies if websockets and Flash are not available (SignalR does as well, just not to Flash first), so it is fully compatible with iOS Safari and Android WebKit

[a_bertrand]

Personally I don't plan to support iOS or Android or any mobile plateform. Why? Because if I do, I would need to limit even the canvas usage (performance) and many other things. So I prefer make my game work well for the desktop than try to make it work badly for all.

[Jackolantern]

Its a good point. The "mobile web" is a great goal for everyone, and really it is there for semi-interactive, non-real time sites, like blogs, forums and news sites provided they make a totally separate CSS file. But mobile web games really are a ways away. As competent as mobile browsers can seem, in reality, they are the poorest, most under-powered and low-featured browsers being used today. As Bertrand said, Canvas hardly works on them at all. Even if it does, actually controlling the game is a nightmare since you don't typically have a keyboard and the screen is too small to control the game with touch.

So for today and the near future, you really have to make a decision to go either completely for desktop browsers or completely for mobile (and if you choose to go completely mobile, it is better to convert your HTML5 game to a full mobile app with something like Caccoon JS or AppMobi). Trying to function equally on both really will make the game suffer.