HTML 5’s Web Sockets explained
I’ve been reading a bit about HTML 5’s WebSockets lately.
First, here are some definitions:
- Comet - an umbrella term referring to techniques that provide “server push” using standard browser functionality — i.e. without the aid of specialty browser plug-ins. In practice, Comet in most-often implemented via Ajax with long polling.
- Long polling - (from Wikipedia) “With long polling, the client requests information from the server in a similar way to a normal poll. However, if the server does not have any information available for the client, instead of sending an empty response, the server holds the request and waits for some information to be available. Once the information becomes available (or after a suitable timeout), a complete response is sent to the client. ”
- Gateway - like a proxy, except gateways don’t alter the requests or response that they ferries between browser and server.
With these definitions out of the way, what are WebSockets?
WebSockets is a new proposal under HTML 5 to provide full-duplex, bi-directional client-server interaction over a single TCP connection. The goal of this proposal is manyfold:
- Increasing web server connection scalability - web applications that leverage WebSockets use half the number of web server connections than do Comet-based applications. Comet requires separate upstream and downstream connections.
- Simplifing the coding task - the WebSocket API is much simpler to code with than the XMLHttpRequest()
Sounds great! So, how do we use them?
Unfortunately, WebSockets require browser support and currently only Chrome supports them (i.e. since version 188.8.131.52). As a stop gap, a company named Kaazing provides a gateway for your existing browsers.
To learn more about WebSockets, check out the links below:
- A good how-to using WebSockets from Tornado’s developer:
- A short introduction to Web Sockets from Kaazing:
- rooksfury posted this