I've just completed implementing WebSocket support into our Mibbit webserver.
The interesting part is this:
Currently, we use XHR long polling, keep alive. Basically a raw socket with some HTTP header spam mixed in.
On the plus side, we can deflate/gzip the contents (unfortunately not across messages, but still does well). But on the negative, the HTTP headers are often about the same size or larger than the contents.
So, webSocket will improve the situation, in that there won't be HTTP header spam. Also we'll be able to use a single connection instead of two (One for sends, one for recvs). On the downside, there also won't be any deflate/gzip (Unless implemented in js etc).
The other big bonus with WebSocket is you can connect to a different port. Something that's not possible (For some idiotic reason) with XHR.
It'll be interesting to see which one wins :)
Pretty cool to see this in Chrome, I thought Firefox would be first to implement it.
Pretty cool to see this in Chrome, I thought Firefox would be first to implement it.
If you wade through the thread, you'll see that someone posted that Firefox/Mozilla had it in trunk for nearly/over a year. Didn't check myself though.
To be fair, Joe Armstrong just adds interest and credibility. It's not as if this is gossip. When you click the link, you get a working example of an Erlang program connecting to Chrome's new web sockets interface.
I believe the key is in the part that says The client connects. The client initiates the TCP connection (thus traversing NAT), which stays alive like any other HTTP 1.1 connection (which has a Content-length header). The server produces the requests, however. I suspect that in order to traverse proxies, the client establishes the original connection via the quasi-standard HTTP CONNECT method which is otherwise used for proxying HTTPS.
This is conjecture, however, as I've yet to research RHTTP.
EDIT: it seems my instinct on proxying was incorrect, other posts imply that the 'Upgrade' header is used. I'm a little surprised that this is widely supported by proxies. I suppose the proxy just keeps the connection open if there's no specified Content-length. Timeouts spring to mind as a potential issue.
N.b. --- those solutions only work for UDP traffic, not TCP; if you want to use them and have a reliable stream protocol you'll end up reinventing TCP atop UDP.
"Reliable" and "stream" are different things. We often use (a variant of) RDP, reliable datagrams. We often want packets with guaranteed delivery, but not necessarily guaranteed order. We also use what we call USP (only partially intentionally to confuse everyone) which is an unreliable stream protocol. Packets aren't guaranteed to arrive, but if they do, they're in the right order.
True indeed (and that's why I used both words), although for a general-purpose protocol intended for wide deployment, you probably want both properties.
I don't think it has a very good success rate. I'm guessing that for a truly reliable TCP solution you would need to throw everything at the wall and hope something sticks: uPNP, NAT-PMP, and maybe this STUNT/ICE-TCP thing.
Am I the only one not excited by WebSockets? It seems like a nice layer over a new Comet method that's even more complex than the long-polling method that we're using today. The server still needs to handle tons of open long-running connections, but with WebSocket you have the added complexity of having to support a brand new protocol in your web server - whatever that may be - instead of one that your web server has supported since it was created.
Personally, I'd rather someone just write a minimal interface (i.e. not Bayeux) to long-running Comet connections using XMLHTTPRequest. It should be trivial after that to make it compatible with the nice API that WebSocket has exposed.
"It seems like a nice layer over a new Comet method that's even more complex than the long-polling method that we're using today."
Exactly backwards. Comet is a thick, ugly layer that is way more complex than sockets. It adds staggering resource overhead to the real abstraction you want; it will in the end be way easier to support a ton of WebSockets than a ton of Comet connections. (That may not be true of pre-optimized implementations, but it will be true of final implementations.)
You don't add Socket support to your HTTP server... you have to add HTTP support to your (TCP) Socket server!
This is the minimal interface; it's Comet that's the hacked up hideous ugly kludge that should never ever have been born because when that dude at Microsoft went to add XMLHttpRequest, if he'd had a clue what that bastard monstrosity would become, he would have created WebSockets right then instead. I don't blame him, it would have taken a lot of vision at the time to understand that. But this is what we should have had from day one, and Comet should never have been.
We have spent a truly astonishing amount of time in the web world deep in the woods, failing to take advantage of simple things that have been known since the 1960s. We've been in the woods so long that people have come to mistake the hacks for the right answer. They're still hacks. Sockets are the not-a-hack. (Though personally I'd still have gone for real sockets.)
I can write maybe 10 lines of jQuery and hook into some of EventMachine's features using Thin as my web application server to use long-polling Comet. I agree that it's not the best solution, but I don't think WebSockets does a great job of fixing it. I also don't have a better idea though, so I suppose I shouldn't be complaining ;-)
But that's not what you were complaining about. You said that sockets were an additional layer over Comet. It's not. The fact that Comet is easy to use if you slather on another couple of layers of code doesn't change that.
Furthermore, you will find, eventually, that WebSockets perform better, both on the client and the server, and there is no amount of jQuery magic that can change that, because the suckiness is fundamental to the nature of Comet. Which again emphasizes the point that it is Comet that is the layer of crap, not web sockets. There's also a lot less that can go wrong since there's a lot less code, and again, slathering on more code on top of Comet can't fix that.
My point is that long-running AJAX requests for Comet really isn't that complex or ugly of a solution. I definitely agree that it's not the most optimal (I believe it can sometimes cause problems once a large number of requests have been made, right?) A solid, native browser implementation is definitely the way to go going forward, but I'm saying that I'm not looking forward to implementing a server for a new protocol that has the same server-side problems as current Comet implementations.
the Bayeux isnt accidental complexity, its hard bolting a bidirectional asynchronous protocol over plain http.
the protocol is simple to implement (10 lines server, 10 lines client for an echo server), and is a completely natural extension to traditional socket programming.
It will be great once web socket support becomes more pervasive. True 2-way communication would be a great boon in the complexity department for a bunch of different types of web apps.
they would need to provide a mechanism to allow connections to non origin domains, like crossdomain.xml
I understand there are security implications, but I wish browser would stop creating prohibitively strict restrictions on web applications and make a somewhat sensible way too elevate permissions
(same origin model, access to the clipboard, etc etc)
Ah. So this is why Google built their own browser. I fully expect to see more goodies coming out of Mountain View in the future. Heck, even I might finally decide to play with web technologies :p
Yeah, I have absolutely no idea why Web Sockets aren't just an initial HTTP request and then a protocol switch (Upgrade header); that would work for the vast majority of proxies and make cookies/same domain/etc work seamlessly.
The protocol has two parts: a handshake, and then the data transfer.
The handshake from the client looks as follows:
GET /demo HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: example.com
Origin: http://example.com
WebSocket-Protocol: sample
The handshake from the server looks as follows:
HTTP/1.1 101 Web Socket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
WebSocket-Origin: http://example.com
WebSocket-Location: ws://example.com/demo
WebSocket-Protocol: sample
The interesting part is this:
Currently, we use XHR long polling, keep alive. Basically a raw socket with some HTTP header spam mixed in.
On the plus side, we can deflate/gzip the contents (unfortunately not across messages, but still does well). But on the negative, the HTTP headers are often about the same size or larger than the contents.
So, webSocket will improve the situation, in that there won't be HTTP header spam. Also we'll be able to use a single connection instead of two (One for sends, one for recvs). On the downside, there also won't be any deflate/gzip (Unless implemented in js etc).
The other big bonus with WebSocket is you can connect to a different port. Something that's not possible (For some idiotic reason) with XHR.
It'll be interesting to see which one wins :)
Pretty cool to see this in Chrome, I thought Firefox would be first to implement it.