6 ms·
WebSockets RFC is now official
- dicroce 15y agoLet the games begin!
- drewblaisdell 15y agoQuite literally. One of the most obvious applications of this is creating asynchronous multiplayer browser games.
- brooksbp 15y agoOh boy. Pretty soon we will need UDP sockets in the browser.
- HoLyVieR 15y agoYou can already do peer-to-peer UDP communication in a browser with Flash RTMFP protocol. If I remember right it was shipped with Flash 10, which got released 4 years ago.
- ricardobeat 15y agoWS 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 15y agoExcept, 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 15y agoThat'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 15y agoWell, 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.
- malone 15y agoI don't understand why they didn't just provide an api to normal IP layer sockets, it would have given a lot more flexibility. I'm thinking the sort of lower level networking access you get in node.js If people really wanted to send data over this weird semi-HTTP websocket protocol then someone could have implemented it as a js library on top of proper socket calls. I'm guessing the main issue was cross-domain security, but I would have liked to see this solved using some sort of policy file that can be requested from the domain before connecting, like Flash does.
- perezd 15y agoNow CouchDB's _changes can support websockets!
- aaronblohowiak 15y agoYay! Looks like they fixed it. Now, it looks like it is a normal upgrade request so proxies, et al, should play nice. Yaaay!
- metabrew 15y agoYep, 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 15y agoI'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 15y ago* try websocket * on failure, fallback to comet It's fairly easy to implement.
- paulbatum 15y agoMany proxies deployed today won't understand the upgrade header and in the case of an explicit proxy config will ignore the CONNECT operation if performed on 80 (rather than 443). WebSockets works best over SSL.
- lkrubner 15y agoI 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 15y agogps 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-with-a-webcam-a-gsp-and-some-fun-part-i/ http://blog.rassemblr.com/2011/07/how-to-hack-a-road-trip-wi...
- notatoad 15y agoYou'll probably want to wait until webrtc to do cool things with voice.
- deleted 15y ago[deleted]
- pingswept 15y agoWebsockets browser support: http://caniuse.com/#feat=websockets http://caniuse.com/#feat=websockets
- sjs 15y agoI let socket.io worry about that. Great library.
- nkassis 15y agoI 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 15y agoIt's something we're currently working on. We're going to be integrating a XHR binary data fallback as well into our realtime engine.
- jmspring 15y agosocket.io is a great library, agreed. However, a nice thing about standards is you can program to the specification and provide support on other platforms. Working on a project that involves node, a browser client, and a couple of mobile platforms -- socket.io is great for the server->browser websocket or comet case, but for the mobile case investigating the proper library (or hand rolling a compatible WS/comet implementation) is needed. The step towards standardization will make this type of cross "platform" compatibility easier in the long run.
- taylorbuley 15y agoLove caniuse.com but unfortunately there's lot missing from this support matrix. More important than which browsers support the API is which underlying protocol version the sockets speak. A lot of major browsers support the API but very few speak the same protocol. I believe today's announcement is a finalized protocol standard which means that there's finally going to be a lingua franca for websockets.
- akg 15y agoAwesome! Should be interesting to see a slew of new collaborative tools and games coming out soon!
- d0mine 15y agolink to html version: http://tools.ietf.org/html/rfc6455 http://tools.ietf.org/html/rfc6455 instead of the plain-text one: http://www.rfc-editor.org/rfc/rfc6455.txt http://www.rfc-editor.org/rfc/rfc6455.txt
- DarrenLehane 15y agoIncredible news. This day couldn't come soon enough.
- curiouskat 15y agoWhat's the best option for using websockets with Python? WSGI doesn't support it (http://librelist.com/browser//flask/2010/9/1/flask-and-websockets/#c5cd3883a8012c672792106000e11c63 http://librelist.com/browser//flask/2010/9/1/flask-and-webso...). gevent is an option (http://blog.pythonisito.com/2011/07/gevent-zeromq-websockets-and-flot-ftw.html http://blog.pythonisito.com/2011/07/gevent-zeromq-websockets...), but would something like Mongrel2 be better (http://mongrel2.org/ http://mongrel2.org/)? UPDATE: There's also Juggernaut (http://flask.pocoo.org/snippets/80/ http://flask.pocoo.org/snippets/80/), which uses node.js under the hood.
- twism 15y agoI have had a lot of success with Tornado ... http://www.tornadoweb.org/documentation/websocket.html http://www.tornadoweb.org/documentation/websocket.html
- stuartk 15y ago+1 for tornado. And I also use Tornadio, which implements the backend for Socket.io.
- zaphoyd 15y agohttps://github.com/oberstet/Autobahn https://github.com/oberstet/Autobahn is another option
- theturtle32 15y agoAutoBahn is an absolutely top notch implementation of WebSockets for twisted. It's probably one of the most complete and robust implementations on any platform, and their test suite is currently the gold standard against which other implementors test their own implementations.
- hackforlife 15y agohttps://github.com/MostAwesomeDude/txWS https://github.com/MostAwesomeDude/txWS Twisted gives you the foundation for pretty amazing things to start with, and txWS does a good job of adding WebSockets.
- draegtun 15y agoFor 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/ http://mojolicio.us/ * PocketIO which is a Perl implementation of SocketIO - https://github.com/vti/pocketio https://github.com/vti/pocketio * Protocol::WebSocket module which adds WebSockets to the PSGI (Plack) stack - https://metacpan.org/module/Protocol::WebSocket https://metacpan.org/module/Protocol::WebSocket
- zurn 15y agoITYM "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 15y agoBut RFCs don't change every month, which is the real milestone being celebrated here.
- easy_rider 15y agoNote 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.
- perlgeek 15y agoMojolicious, a modern Perl web framework, has great support for WebSockets. Check out http://mojolicio.us/ http://mojolicio.us/
- draegtun 15y agoYou probably couldn't see my earlier Perl comment in all the jetsam & flotsam here :) ref: http://news.ycombinator.com/item?id=3342952 http://news.ycombinator.com/item?id=3342952
- jweant 15y agoI had no idea this was in the works (not been reading ietf lately). Wonderful post.