Web Sockets specification (IETF Internet Draft)(tools.ietf.org)
tools.ietf.org
Web Sockets specification (IETF Internet Draft)
http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-54
4 comments
The point is, roughly, making a protocol for browsers to communicate bi-directionally with servers (that is, either side can send data to the other at any time; this spec tries to provide semantics of a TCP socket), which (a) gets through proxies and firewalls, (b) has as little overhead as possible, and (c) has no potential security vulnerabilities not already present in other types of browser connections (XHR, etc.).
Currently, the set of techniques collectively called "Comet" are inconsistent across browsers, fragile to new browser version changes, and extremely hacky.
> The application still needs to implement yet another layer to deal with the data
Well sure, the application needs to implement the semantics of whatever the particular network app is that will communicate with a method like this. But that's always been true for any application. Something like this just tries to give web applications some of the same flexibility that applications with more access to the OS, and which could therefore just open TCP sockets, always had.
Currently, the set of techniques collectively called "Comet" are inconsistent across browsers, fragile to new browser version changes, and extremely hacky.
> The application still needs to implement yet another layer to deal with the data
Well sure, the application needs to implement the semantics of whatever the particular network app is that will communicate with a method like this. But that's always been true for any application. Something like this just tries to give web applications some of the same flexibility that applications with more access to the OS, and which could therefore just open TCP sockets, always had.
As I see it, main technical distinction between WS and straight TCP is that WS is message oriented, not stream oriented. Basically, the spec demands that all data transmissions consist of discrete UTF-8 messages that begin with 0x00 and end with 0xFF.
The message oriented nature of things in theory makes thing easier for writing client code in JS. However, the simple boundary scheme chosen also implies no binary data (of course that is of limited use in a browser without a JS standard for dealing with binary data).
The other technical feature the RFC proposes is a standard way for HTTP clients to securely request and setup one of these web sockets (even though the web sockets themselves are not HTTP). That alone is significant because getting Comet (the current best solution) to work on all browsers is currently a nightmare.
BTW, if you are interested in doing Comet and not pulling your hair out with X-browser issues, I highly recommend the orbited project (orbited.org) and its sister bundle of JS code (js.io). These projects already provide an interface very similar to the proposed spec. I have used this API and it makes me look forward to Web Sockets becoming a standard.
The message oriented nature of things in theory makes thing easier for writing client code in JS. However, the simple boundary scheme chosen also implies no binary data (of course that is of limited use in a browser without a JS standard for dealing with binary data).
The other technical feature the RFC proposes is a standard way for HTTP clients to securely request and setup one of these web sockets (even though the web sockets themselves are not HTTP). That alone is significant because getting Comet (the current best solution) to work on all browsers is currently a nightmare.
BTW, if you are interested in doing Comet and not pulling your hair out with X-browser issues, I highly recommend the orbited project (orbited.org) and its sister bundle of JS code (js.io). These projects already provide an interface very similar to the proposed spec. I have used this API and it makes me look forward to Web Sockets becoming a standard.
My guess is Google found it useful, and wanted to share it, so it's their gift to the world.
I really don't understand what problem this draft solves, and the draft doesn't seem to explain it coherently.
It effectively describes just another layer on top of TCP that implements its own addressing, loosely follows HTTP syntax and utilizes TLS for security. The application still needs to implement yet another layer to deal with the data carried by this protocol. So instead of using (TLS + application protocol) combo, the app needs to use (TLS + WS + application protocol).
So what's the point in making this protocol a standard ?
-- PS --
Historically, creating an instant messenger chat client as a Web application has required an abuse of HTTP to poll the server for updates while sending upstream notifications as distinct HTTP calls.
Perhaps that's how they do it at Google, but historically applications like httptunnel simply opened exactly two persistent HTTP connections - one with a very long POST and the other one with a very long GET - and used them to send data up and down respectively.