Mibbit supports WebSocket, some initial numbers. | Hacker News Reader

Mibbit supports WebSocket, some initial numbers.

axod.blogspot.com

84 pointsaxod19 comments

FWIW also:

Browser usage on Mibbit main client (Snapshot):

  FX3: 65%
  Chrome: 12%
  IE8: 7%
  IE7: 6%
  Opera: 3%
  IE6: 3%
  Safari: 3%
  FX2: 1%

Chrome has really grown at an astounding rate in the webapp usage world at any rate.

We're getting 9.4% on our sci-fi game. Geeks do love Chrome.

Wanna share what game? You might get another player ;)

http://apps.facebook.com/starfleet_commander

I'm a Chrome loving geek, but I'm far outnumbered by the non-technical, non-geeks that I've converted to Chrome based on its superior security and stability.

Among my friends, that's step 1 when you get roped into doing family tech support anymore: remove the IE shortcuts, install Chrome. Only sometimes changing the chrome shortcut to the IE icon...

Even my mum uses Chrome now :/ I think it's going to be more mainstream than firefox in the end.

Thanks, that's really interesting.

I have been playing with web workers (http://github.com/revis/Really-Cloudy) and one thing that worried me was the number of people with capable browsers. From your data it looks like that isn't a problem for technical audiences.

I'm so happy to see FX3 at 65% and less domination of IE :)

Atleast some webapp makers and users don't care about IE.

Very interesting and exciting. I'd like to see some numbers on lag though, as it seems that WebSocket uses just about the same amount of bandwidth.

I think the bit outstanding question is about scale.

The comet connection requires 2 keep-alive HTTP connections to make a full-duplex connection. So obviously a single socket connection doubles the number of users a single box can handle - does it actually scale that way?? Don't know.

You've also got to wonder about the extra overhead of running deflate on everything that you send with the XHR version of the code, and why there couldn't be some sort of compression applied to the packets sent through WebSocket if it is a really big deal.

Also, obviously, the smaller your send/receive, the better the improvement that your websocket code would see over XHR. I can imagine an application of websockets where you open multiple sockets and send a number of constantly updating data-streams from the server.

A lot of articles seem to imply that websockets is simply XHR 2.0, and I'm sure it will be used as such for a while.

But it seems to me that there are certain things that you can do with this that simply cannot be done efficiently with other technology.

(Imagine being able to smoothly track a mouse cursor or watch another person edit a document in real time, how would you do that with XHR?).

>> "or watch another person edit a document in real time, how would you do that with XHR?"

Works fine on Etherpad.

Having said that, I agree, the lag with WebSocket is likely to be a less. Hopefully WebSocket will get the ability to do deflate/gzip soon as well. That would make it a very clear winner.

Works fine but doesn't work in the same way.

On etherpad there is a lag and updates get chunked.

With websockets you could do it by the keystroke with little to no overhead.

Really? You're still sending packets, so instead of sending roughly 1k of data, you're going to send a packet with roughly 1 byte of information on each keystroke?

What I'd really like to see is the breakdown of the number of packets sent as opposed to the number of bytes. I doubt the difference would be as significant.

At a full 60WPM ~= 60 * 6 keystroke per second *1kb/keystroke~= 360kb / second. However, clunking at 1/20th of a second is probably fine.

Great post and crash course in long lived HTTP.

Did you write your own http server/library or are you using an existing one for the current Comet implementation?

I wrote one in Java/NIO. It runs in a single thread, does SSL, async DNS lookups, proxying, comet, websocket.

I really hope someday to open source it sometime. If only to show people that development in Java doesn't have to be horrible.

What I don't get is why more people haven't been using Flash's socket support (XMLSocket, and the more general-purpose flash.net.Socket in AS3) for this sort of thing. Flash is installed on practically all web browsers, and you can still write the rest of your app in JS if you want by using ExternalInterface.

For extra credit, you could probably write a WebSocket implementation IN Flash using these techniques. Anyone on it?

There are a lot of simple flash shims out there -- I'm using one for my app, with everything else written in javascript. For me, switching to websocket would be more or less ceremonial rather than practical.

Reply on news.ycombinator.com