tags:

views:

111

answers:

2

This is more of a n00b question, but I've never really known the answer.

so why do we need the websockets protocol?

and, what are the advantages over comet-style/long poll/hanging GET-style use of HTTP?

+2  A: 

Comet and Ajax can both deliver end-user experiences that provide desktop-like functionality and low user-perceived latency, only Web Sockets lives up to the promise of providing a native means to accurately and efficiently stream events to and from the browser with negligible latency.

With polling it makes unnecessary requests and, as a result, many connections are opened and closed needlessly in low-message-rate situations.(as with polling it sends HTTP requests at regular intervals and immediately receives a response.)

Web Sockets remove the overhead and dramatically reduce complexity.

Spooks
Web-sockets are AJAX live-updating done right :)
Lethargy
A: 

It isn't clear that we do need them. In the scenario of pushing events to the client, a page can make ordinary AJAX GET requests in a loop, and the server can "hang" until events are available. After some timeout passes the server can return a "no events" response so the client will reconnect. During the period where the connection is open and the client is waiting for a response, there is an effective push channel from the server back to the client.

The timeout period can be adjusted to reduce the amount of unnecessary reconnecting, though it cannot typically be infinite because most server frameworks will terminate the server-side process if it appears to have hung for too long.

Given this existing capability, the question is: does a new communication framework really add significant value over what can already be done? It wouldn't really enable something that cannot be done. It would only slightly improve it.

Daniel Earwicker
How would you implement something like a BitTorrent client or a VNC client using `XmlHttpRequest`?
Jörg W Mittag
You would implement "something like" them by cooking up an analogous protocol over HTTP. For a joke I once did a socket tunnelling proxy over HTTP where one side would post data to a web app and the other side would read the data and ferry it on, thus simulating a stream in terms of lots of separate HTTP transactions. To my surprise it was actually quite usable as a conduit for Microsoft Remote Desktop sessions. Any existing protocol could be mimicked in that way. Quite why you'd want to do it is another question.
Daniel Earwicker