Web Sockets in Tornado - Bret Taylor's blog - http://bret.appspot.com/entry...
Dec 31, 2009
from
Louis Gray,
Steve Gillmor,
eugenio,
Sinan Duman,
Emre M.,
f(z),
t toring,
Orlando Pozo,
Kazutaka Ogaki,
imabonehead,
Shakeel Mahate,
Ozgur Demir,
Joel Webber,
Susan Beebe,
Chris Messina,
Özkan Altuner,
Hein Roehrig,
Сло,
Bruce Lewis,
alfred westerveld,
Eric - Final Countdown,
Tudor Bosman,
Tracy,
Michael R. Bernstein,
Matt M (inactive),
and
Mark Trapp
liked this
Is there any way to use Web Sockets on Google App Engine (Python)?
- Michael R. Bernstein
What Gary said. Specifically, systems like AppEngine are meant to be scalable by strongly encouraging (well, requiring, for all intents and purposes) a stateless server model. A long-lived socket connection, by contrast, is meant to do the precise opposite. I suspect the AppEngine team is thinking about this sort of thing w.r.t. XMPP and WebSockets, but I'm not sure how they'll resolve this dichotomy.
- Joel Webber
I agree, Gary, you definitely have to deal with dropped connections on both sides to make apps work correctly. On the server side, the code looks almost identical to the long-polling code, except you "send a message" rather than finish the HTTP response, but I don't think you can get rid of the concept of cursors and connection restarts without losing messages on dropped connections.
- Bret Taylor
What are "cursors" in this context? Seems like the logical thing would be to have a message queue fabric that uses WebSockets and/or other transports to send, receive, and acknowledge messages, with stateless handlers that are invoked for incoming messages, can access storage resources, and can enqueue new outgoing messages (not necessarily to the same client). (I don't know anything about GAE's plans.)
- ⓞnor
Right, thanks. The message fabric would need to have message queues which can be indexed with the cursors. So state is kept in the message queues ("above") and the storage layer ("below"), but message handlers (app logic) can be stateless. This model might not be very efficient if you have to keep loading and saving a lot of state for every message, but you have that problem with HTTP servers too, and the same solutions (memory based cacheservers, sticky-but-unreliable session objects, etc) apply.
- ⓞnor
No question that sockets *can* be used in an essentially stateless manner, as long as both sides are resilient to dropped connections. One assumes the servlet/handler/whatever would need to be terminated automatically when resources are needed. But the server would need to be very carefully constructed such that it could always recover lost state when this happens.
- Joel Webber
Agreed, Gary. But for something like AppEngine, we're talking about the need to be resilient to the equivalent of a server restart with very little notice, more frequently than would happen naturally. I believe this would mean being essentially stateless, even though you're keeping a socket connection open to a client, which is certainly possible, but not a necessity one would expect under more "normal" circumstances. Perhaps AppEngine could allow stronger guarantees (e.g., a given frontend will stay up until it receives a death signal, at which it has X seconds to persist its state somewhere), but I doubt this is a trivial change.
- Joel Webber
Bret, I love this web socket daemon feature, hope all the web clients/servers implement this API soon.
- Orlando Pozo
1000% easier, huh!
- Emre M.