The system works as follows:
- When a user makes a request to the site
- ...the request is handled by a Google App Engine application
- ...that puts the request into a request queue
- ...a comet-client maintains a pseudo permanent connection to the App Engine app
- ...looks into the request queue and starts to process the request
- ...when it is finished it sends the response to the App Engine app
- ...which immediately send the request back to the client that originated the request in the first place.
- Ressouce requirements on the server side are reduced because every client can share some of its own ressources with every other user of the system
- Enables absolutely seamless integration of client- and server software
- Every app server is totally untrusted.
- Google App Engine unfortunately does provide a good way to implemented comet-style applications with long-polling because they enforce very strict rules with respect to request timeouts
- The App Engine SDK builtin-web server is not multi-threaded. Thus the application can not be tested (easily) within the SDK but has to be deployd to the production system.
- My implementation is very-very proof-of-concept do-the-easiest-thing-that-could-work style with no error checking and various evil race conditions with respect to the request queue.
- There is currently no way to read-or-write HTTP headers from the applications
You can try the the demo application (a simple counter here). It will only work if you either started the server yourself (below) or if somebody else is currently running the server application.
The server is running in this iframe:
The app engine application might be disabled due to overuse of quotas. If that is the case, I'm sorry.
If you are interested in come code, check out the implementation of the server.