31–40 of 47 posts
I look forward to pushing this to the absolute limit. Chat? Can we do something cool with voice? What about websites-as-desktop-software that started when Ajax got cool, but paused when developers ran into the limits of Ajax? How far can that now go? GPS services?
What's the best option for using websockets with Python? WSGI doesn't support it ( http://librelist.com/browser//flask/2010/9/1/flask-and-webso... ). gevent is an option ( http://blog.pythonisito.com/2011/07/gevent-zeromq-websockets... ), but would something like Mongrel2 be better ( http://mongrel2.org/ )? UPDATE: There's also Juggernaut ( http://flask.pocoo.org/snippets/80/ ), which uses node.js under the hood.
What's the best option for using websockets with Python? WSGI doesn't support it ( http://librelist.com/browser//flask/2010/9/1/flask-and-webso... ). gevent is an option ( http://blog.pythonisito.com/2011/07/gevent-zeromq-websockets... ), but would something like Mongrel2 be better ( http://mongrel2.org/ )? UPDATE: There's also Juggernaut ( http://flask.pocoo.org/snippets/80/ ), which uses node.js under the hood.
We use it successfully at SiteSupport (http://sitesupport.com)
What's the best option for using websockets with Python? WSGI doesn't support it ( http://librelist.com/browser//flask/2010/9/1/flask-and-webso... ). gevent is an option ( http://blog.pythonisito.com/2011/07/gevent-zeromq-websockets... ), but would something like Mongrel2 be better ( http://mongrel2.org/ )? UPDATE: There's also Juggernaut ( http://flask.pocoo.org/snippets/80/ ), which uses node.js under the hood.
I have had a lot of success with Tornado ... http://www.tornadoweb.org/documentation/websocket.html
Earlier quoted context omitted.
Except, it's implemented on top of TCP. So you still have the head-of-line blocking problem. In a real-time application like games, if some congestion causes a few packets to be dropped, you don't care about them any more (assuming your protocol gives absolute positions of everyone involved); but in TCP, they will be retransmitted, and later packets queued until it can catch up. As websockets are based on TCP, you ca…
That's true, but in practice networked games built on websockets are doing fine right now, and will until browsers get stable capabilities for more intensive 3D gaming (likely in around 2 years time). I guess I meant they won't be needed yet .
Since all we get is TCP right now though, you can take advantage of that at least and easily do things like send deltas instead of absolute positions, and even things that depend on reliable order of transmission (which you can't rely on if it were UDP), in order to reduce bandwidth use.
* Mojolicious web framework which managed to keep up with the constantly moving standard! - http://mojolicio.us/
* PocketIO which is a Perl implementation of SocketIO - https://github.com/vti/pocketio
* Protocol::WebSocket module which adds WebSockets to the PSGI (Plack) stack - https://metacpan.org/module/Protocol::WebSocket
Yay! Looks like they fixed it. Now, it looks like it is a normal upgrade request so proxies, et al, should play nice. Yaaay!
Yep, they undid the crazy 8 bytes of body that wasn't declared by content-length, back in hixie-76. The current protocols play nicely with HTTP aware proxies now. They introduced plenty of other crazy things.. but at least it works with proxies.
At least with hixie-76, connections would fail to connect if the intermediate proxies are not understanding WebSockets. Now, your connection will succeed, both client and server will believe they can successfully communicate, but communication will not work and die a slow timeout. Not very reliable, is it ?
Publication as an RFC doesn't signify any status of the protocol standards-wise, almost any protocol can be documented in an informational, experimental or historical RFC.