

Mibbit supports WebSocket, some initial numbers. - axod
http://axod.blogspot.com/2009/12/websocket-some-numbers.html

======
axod
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.

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

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

~~~
mattmaroon
<http://apps.facebook.com/starfleet_commander>

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

~~~
anonjon
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?).

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

~~~
anonjon
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.

~~~
mbreese
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.

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

------
dschobel
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?

~~~
axod
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.

------
duskwuff
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?

~~~
mcav
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.

