Erlang Creator Joe Armstrong Wants to Ditch AJAX, Loves Chrome's New Web Sockets | Hacker News Reader

Erlang Creator Joe Armstrong Wants to Ditch AJAX, Loves Chrome's New Web Sockets

groups.google.com

116 pointsxanados36 comments

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.

Sometimes I'm glad I'm not famous enough to have everything I say scrutinized and re-broadcast.

http://twitter.com/shawndrost/status/6547879113

Just sometimes?

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.

> Websockets let you use RHTTP. The client connects, sends a request to switch to RHTTP, then becomes an HTTP server.

This isn't going to be another SIP, is it? 'Yes we've all agreed on this protocol, off you go and use it. NAT? What's NAT? Is it important?'

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.

Well, the NAT issue is almost solved with STUN [http://en.wikipedia.org/wiki/STUN] and TURN [http://en.wikipedia.org/wiki/Traversal_Using_Relay_NAT] (in those cases where STUN is not enough). Together they make ICE [http://en.wikipedia.org/wiki/Interactive_Connectivity_Establ...].

But none of these is needed for websockets to work.

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.

Such variants have their places.

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.

There is STUNT for that, but I have no idea about its current status. [http://nutss.gforge.cis.cornell.edu/stunt.php] [http://tools.ietf.org/html/draft-ietf-mmusic-ice-tcp-08].

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.

I think the RHTTP bit is someone confusing WebSockets with Opera's builtin webserver thing.

(No mention of reverse HTTP in http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-...)

Edit: Disregard that I need coffee. (Aka, I'm the one confused about Opera's builtin webserver 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.

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.

I am pretty excited by it.

"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.

If the AJ in AJAX uses web sockets instead of XMLHttpRequest, isn't it still AJAX?

Besides which, the X in AJAX is JSON often enough nowadays.

I guess it would be AJWS then. They're going to have to come up with a better acronym than "Adj-wuss" before this thing takes off.

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.

Could I have a bittorent client running in Chrome?

Uh, I guess. They needed some way to support all the communication applications on their browser-OS after all...

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)

In addition, the NAT issues discussed elsewhere in this thread would also be a much bigger deal with P2P.

Something new to play with. Joe hits the sweet spot, regarding powerful & pragmatic, again.

Websockets + Erlang... nice.

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

As they discuss, will proxies have to specifically enable Web Sockets to allow this to replace AJAX?

I thought this was the same problem Flash sockets had, traffic being blocked.

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.

From the web socket spec:

  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

Well, that explains my disbelief. Thanks!

I think the biggest problem with flash sockets was the flash part :)

the biggest problem with flash sockets is the insane security policy file business.

Reply on news.ycombinator.com