

WebSockets RFC is now official - Qwl
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg09663.html

======
curiouskat
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...](http://librelist.com/browser//flask/2010/9/1/flask-and-
websockets/#c5cd3883a8012c672792106000e11c63)). gevent is an option
([http://blog.pythonisito.com/2011/07/gevent-zeromq-
websockets...](http://blog.pythonisito.com/2011/07/gevent-zeromq-websockets-
and-flot-ftw.html)), 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.

~~~
twism
I have had a lot of success with Tornado ...
<http://www.tornadoweb.org/documentation/websocket.html>

~~~
stuartk
+1 for tornado. And I also use Tornadio, which implements the backend for
Socket.io.

------
pingswept
Websockets browser support: <http://caniuse.com/#feat=websockets>

~~~
sjs
I let socket.io worry about that. Great library.

~~~
nkassis
I agree about socket.io. It works quiet well for most of what I need. The only
issue I have with is is I can't figure out if it now supports sending and
receiving ArrayBuffers? Does anyone know anything about this?

My use case involves sending model data to display in WebGL. Sending it any
other way would be inefficient.

~~~
Rauchg
It's something we're currently working on. We're going to be integrating a XHR
binary data fallback as well into our realtime engine.

------
draegtun
For Perl mongers interested in WebSockets then take a look at...

* 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>

------
aaronblohowiak
Yay! Looks like they fixed it. Now, it looks like it is a normal upgrade
request so proxies, et al, should play nice. Yaaay!

~~~
metabrew
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.

~~~
koen
I'm not to happy with this change though.

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 ?

~~~
maximusprime

      * try websocket
      * on failure, fallback to comet
    

It's fairly easy to implement.

------
perlgeek
Mojolicious, a modern Perl web framework, has great support for WebSockets.
Check out <http://mojolicio.us/>

~~~
draegtun
You probably couldn't see my earlier Perl comment in all the jetsam & flotsam
here :)

ref: <http://news.ycombinator.com/item?id=3342952>

------
perezd
Now CouchDB's _changes can support websockets!

------
d0mine
link to html version: <http://tools.ietf.org/html/rfc6455>

instead of the plain-text one: <http://www.rfc-editor.org/rfc/rfc6455.txt>

------
lkrubner
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?

~~~
_pdeschen
gps service? checked!

Well kind of. Last summer I did a road trip to newfoundland (canada) with a
laptop, a gps and a webcam onboard [1]. The idea was to have people (friends
and family) to follow our trip through a website to which I pushed webcam
frames and gps coordinate in real time using websocket (socket.io) over my
smarthphone. It was fun!

[1]: [http://blog.rassemblr.com/2011/07/how-to-hack-a-road-trip-
wi...](http://blog.rassemblr.com/2011/07/how-to-hack-a-road-trip-with-a-
webcam-a-gsp-and-some-fun-part-i/)

------
zurn
ITYM "WebSockets is now officially IETF Proposed Standard" or something like
that.

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.

~~~
wmf
But RFCs don't change every month, which is the real milestone being
celebrated here.

------
dicroce
Let the games begin!

~~~
drewblaisdell
Quite literally. One of the most obvious applications of this is creating
asynchronous multiplayer browser games.

~~~
brooksbp
Oh boy. Pretty soon we will need UDP sockets in the browser.

~~~
ricardobeat
WS is already kind of fire-and-forget. Socket.IO supports that, and can handle
thousands of messages/second, I don't think that will be needed.

~~~
lambda
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 can't avoid this. Even if you have a
"fire and forget" message based layer built on top of TCP, the head-of-line
blocking will still kill your performance, causing people with bad connections
to get persistent lag rather than a few dropped frames.

~~~
ricardobeat
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_.

~~~
ehsanu1
Well, I'm working on a web-based real-time multi-player game, and I'd say that
UDP would be very welcome by me. When I'm on a good connection, TCP is fine
and things work perfectly. But as soon as my connection becomes just a tiny
bit unreliable and packets start dropping, it becomes completely unplayable,
as TCP has to retransmit those dropped packets before any new packets are
processed.

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.

------
easy_rider
Note to self: don't start reading RFC's when you're supposed to go to bed to
get up for work in time the next morning.

------
akg
Awesome! Should be interesting to see a slew of new collaborative tools and
games coming out soon!

------
DarrenLehane
Incredible news. This day couldn't come soon enough.

------
jweant
I had no idea this was in the works (not been reading ietf lately). Wonderful
post.

