The traditional web model is a request/response based model. The client requests a resource from the server, the server does some processing and returns the resource. 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!
http://channelapistresstest.appspot.com/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 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 can result 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.
Cross posted to AltDevBlogADay which has some great comments.