In-depth: Channel API

[In this reprinted #altdevblogaday in-depth piece, freelance senior programmer Noel Austin, shares his results after testing the performance of Channel API with Google App Engine.] I'm sure you've heard of Google App Engine – it's a web hosting service that allows you to write server software in Java, Python or Go. Overall I think it's a great piece of technology that helped me understand the concept of writing scalable services. It was also a useful reason to finally learn Python. Anyway I'm currently interested in the suitability of it for real-time applications like games. The traditional web model is request/response based. The client requests a resource from the server, the server responds with some data. That's the end of the transaction. In this model, there is no way for the server to update the client without first receiving a request from that client. If you want to build a multiplayer game, then this is likely to be very important. It can be simulated either by regular polling from the client (does not scale well), by some fairly hacky techniques falling under the umbrella of Comet, or by the new WebSockets technology available recently. Google App Engine does not support WebSockets, but it does support Comet under the guise of the Channel API. Test App Here! I was interested in the performance of the Channel API, so I wrote a small test app. I'm a bit of a noob when it comes to Python and HTML/Javascript, but if you want to take a look I uploaded my code here. Overall I was disappointed with the results, and it indicates to me that if you want any kind of fast response game, then you may have to look elsewhere.

• Very unpredictable latency (200-1000ms)
• Big packet overhead of HTTP headers etc
• No peer to peer support at all (limitation of current web technologies)
• No support for broadcast messages (server must send to each client in separate call)
• Sending several messages at once often results in a massive increase in latency

That said I do think the technology is quite promising and certainly opens up the possibility of doing whole classes of games with two-way communication -- strategy games, or other games where one player does not directly affect another. Adding chat, for instance, is a perfect use case for this. If you are thinking about using Channel then I found out a few things that might be useful to you:

• Reliable – in all my tests, all messages eventually arrived
• Out of order – messages are not guaranteed to be in sequence, so if this is important you need to handle your own sequence checks
• Multiple instances – don't forget the service may spin up multiple instances to handle the requests
• Development server is much worse than the live server (on Windows at least) – it seems to serialize all messages sent with approximately 600ms between each one

I checked the latency from my office in the UK and found it to be very unpredictable and often slow. If anyone from other parts of the world could test and report back your average latency, that would be awesome! It's entirely possible that I've screwed something up, which is causing the poor performance. If anyone has any comments on this, it would be great to hear them. Addendum After writing this, I became interested in comparing the Channel API with Websockets. I took this opportunity to play with node.js and hack up a quick server. I found a great host in nodejitsu, who provided one free app and a fantastic tool to deploy your app. Unsurprisingly results are much better than with Channel. My average latency tends to hang around 200ms, but there are no spikes or degradation when sending a lot of messages. You can test my quick and dirty app at http://echo_test.jit.su/ (sorry it only works in Chrome/Firefox!). You can see the source here. It is not really a fair comparison, because the back ends are designed for different purposes. The GAE server uses persistent storage to support multiple instances, whereas the node.js version will not scale. The Channel API is also fully supported on all browsers/platforms whereas support for WebSockets is still fairly thin on the ground. [This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]