

How WebSockets work vs polling/long polling/streaming - SkyMarshal
http://www.websocket.org/quantum.html

======
strictfp
I find it amusing that TCP was designed as and still is a full-duplex protocol
for long-lived connections (streams). Then someone decides to use it in HTTP
(1.0) for short-lived, half-duplex, message-oriented communication. Not
surprisingly, it is not a good fit. Fast-forward a couple of years and
everybody is busy de-crippling TCP in HTTP with various hacks trying to delay
the HTTP request-response cycle, thus uncovering the streams in the underused
underlying protocol. First now, many years later, the mistake is properly
corrected and TCP on the www is vindicated through websockets. Funny world.

~~~
EternalFury
Wait a little longer and, if we are very lucky, multicast will be "re-
discovered" as well. That way, instead of having servers shove data down many
sockets to many clients, they will write their payload down 1 multicast socket
to all interested clients, with said payload crossing the network as little
and as far as necessary but not more.

So goes the wheel of progress...

~~~
randall
Multicast is a nightmare over the general internet, from what I hear. It'd
need some significant tooling to work properly.

------
johnyzee
He seems to play up the problems with comet-style communication quite a bit.
Most of his objections, and it seems the entirety of his 'showdown' is based
on using the slowest comet implementations, which do repeated HTTP requests,
rather than the obvious and, as far as I know, most commonly used streaming
approach. Honestly, I see little difference between streaming comet
communication and web sockets in terms of performance/overhead.

And why does the "Complexity of comet applications" diagram show "RIA client
app" (does this not have to be built when using web sockets?), "Silverlight or
Flash plugin" (as if these are necessary for comet), and some convoluted
server-side architecture that has nothing to do with the client-server
protocol? Again it seems like trying to play up the deficiencies of comet-type
apps in a kind of disingenious way.

Web sockets seem to be a great step forward in almost every way (cross-
platform support currently missing) so why hype them with imagined performance
wins from unrealistic comparisons with other solutions.

~~~
mikescar
Yes, and then you get down to the Kaazing sales pitch, where a diagram shows
your packets just going out to the Internet, and there's no longer any
management to do on the client.

A well written article otherwise though. I appreciated the reminder to audit
the headers you're sending out as an easy way to improve performance.

------
davidpardo
Looks like an advertorial. No mention of socket.io and praise for a commercial
solution that I didn't know after almost two years working with websockets.

~~~
TazeTSchnitzel
Yup. It is an advertorial. Kaazing like promoting their own "WebSocket
Gateway", and they're in a great position to, owning websocket.org

By the way, at the moment I'm using Python's Twisted with a simple wrapper
called txWS: <https://github.com/MostAwesomeDude/txWS>

I'm not a big fan of socket.IO, seems too complex for my needs. I was quite
happy to discover txWS, it's literally one more function call and you can just
write ordinary Twisted code with no changes, which is a relief.

Edit: I'm tempted to purchase websockets.co...

~~~
TazeTSchnitzel
Update: I went and bought websocket.us and websockets.us, and put up my own
small website about WebSockets. I just want to provide an alternative to
Kaazing's site, that has no commercial focus.

~~~
ralph
As a link, <http://websocket.us/>

------
Liongadev
Their claim that "HTML5 Web Sockets can provide a 500:1 or—depending on the
size of the HTTP headers—even a 1000:1 reduction" is also wrong as they dont
account for TCP / IP Frame overhead. Sure it still is around 50:1, and sockets
are awesome. But if you present numbers, please dont present misleading
numbers.

------
cagenut
I get the basic idea, but when I try to flush it out into a full cluster and
app design long-poll/web-sockets seems like a bit of a complexity nightmare on
the back end. I mean you're taking a highly cachable stateless protocol and
turning it into an uncachable one. Then you're taking a shared-nothing
application layer and forcing it to do shared-state cache coherence via
message passing. And all the way up and down the stack you're turning what was
overwhelmingly treated as a request/response model and turning it into a
different one. Every cache, proxy, application firewall, traffic shaper,
loadbalancer and IDS on both sides is going to 'get confused' and net out to a
toooon of user complaints and corner cases.

~~~
strictfp
Exactly. Ajax in general breaks REST, including bookmarking, caching,
navigation and more. All major selling points of HTTP goes out the window.
HTTP was created on top of TCP, but with severe restrictions to get the great
features which HTTP is well-known for. Now someone re-lauches unrestricted TCP
as a feature, when it is in fact much more simplistic and formed the base all
along. Usage was purpously off limits due to the headaches that unrestricted
client-server communication causes.

~~~
rogerbinns
> Ajax in general breaks REST

Huh? You are supposed to correctly choose the HTTP verbs and URI path
precisely so that HTTP semantics apply.

If you are talking about page state then there are numerous ways of dealing
with that - one example is <http://diveintohtml5.info/history.html>

If your assertion is that developers _can_ write bad code, abuse HTTP
semantics, defeat caches, break navigation etc then so what? With the ability
to do things right comes the ability to mess them up.

~~~
strictfp
I am saying that by using Ajax to partially update a page, that updated page
no longer has a URL which identifies it. This breaks HATEOAS badly. The idea
of REST is that every state on a site has a representation. REepresentational
State Transfer you know... So while there are many other ways of shooting
yourself in the foot when designing a REST website, using Ajax makes it almost
inevitable.

------
peterlubbers
Just to let you all know that this is an old article (agree that a publish
date would have helped there). Frank and I published this article originally
in late 2009 or early 2010. That was around the time that WebSocket first
landed in Chrome and there have been a lot of updates to the protocol since
then. For example, WS was text only, and I don't think socket.io existed yet
;-)

------
lenkite
"..., it cannot deliver raw binary data to JavaScript, because JavaScript does
not support a byte type" Incorrect. JS most definitely supports binary data
using byte arrays with Uint8Array, etc or using canvas data binary

------
halayli
spdy is better designed and supports compression out of the box. I also don't
think that a network protocol should be part of HTML5 standard.

~~~
TazeTSchnitzel
The WebSocket protocol isn't part of the HTML5 standard. The API is, but
WebSocket's protocol is not defined in HTML5.

~~~
halayli
The fact that it's mentioned in HTML5 API bothers me.

~~~
TazeTSchnitzel
Why? They are _Web_ Sockets, and we have AJAX already.

~~~
halayli
Ajax is merely a client JS interface to HTTP. A protocol that already exist.
It's not a protocol being imposed on web servers.

When you want to impose a new protocol on web servers and browsers, it better
not be to solve push notifications only. And that's what SPDY did.

~~~
TazeTSchnitzel
WebSocket isn't just to solve push notifications. It's also for realtime
communication, for example chat or multiplayer games. We do have server-sent
updates if you just want push notifications.

~~~
halayli
yes, without compression. Everything you said is covered in SPDY. But SPDY
takes a step further and improves the current state of HTTP as well to better
transfer documents.

