Google App Engine: Browser to Server persistent connection

I've been playing around with the Google App Engine channel API to create a real-time multiplayer game similar to http://rawkets.com/. Since this API is basically "one way" (doesn't enable a persistent browser-to-server connection), I am just issuing new AJAX POST requests (JQuery) at about 30/second.

It seems to be generating a large overhead (5-6kb/second), which I would like to reduce if possible. Ideally I would like to create only one connection that lasts a bit less than 30 seconds (the appengine request timeout) and continues to send fresh da开发者_开发技巧ta every 30 milliseconds for the duration of the connection. The server would then use the channel API to "spread the word" to all other relevant clients. Hope this makes some sense!

Any ideas?

---

There are two major problems with creating long-lived connections yourself.

1. You can't stream output from the server, it will be buffered then sent when the handler exits.
2. Your app will not be auto-scaled if your requests do not return in under 1,000ms.

As sje397 mentions, the Channel API currently does not support general broadcast -- you would need to implement your own. However, if you are just trying to push to several nearby players, implementing your own solution may not be an issue.

What are you attempting to do every 30ms? You'll need a very well thought-out design, just reading and setting a value in memcache is going to consume close to half of that time. If you need to query the datastore, you'll probably be over that.

---

Broadcast doesn't work too well using the built-in channel API (although they have said on the mailing list that something is in the works).

You might want to check out a third-party 'real' websockets provider. For example, http://pusherapp.com.

---

This simply isn't how HTTP works - it sounds like what you want is closer to the (forthcoming) websockets API, which isn't widely supported in browsers yet, or supported at all by App Engine.

Still, 30 requests per second per client seems particularly absurdly high - there's no way a single user on a keyboard can generate that many events.