HTML and CSS Reference
In-Depth Information
it like a normal request. The client processes the data sent from the server and then opens a new request immedi-
ately to wait for more data. This mechanism enables the server to send data to the client; however, the overhead
associated with creating a new socket for each piece of data pushed in either direction means that performance
suffers.
Flash had socket support for a long time, so another workaround was to use a Flash socket via a loaded SWF
that has an interface exposed over a Flash-to-JavaScript. One problem with Flash sockets, however, is that to
also serve normal HTTP requests on the same server, they need to exist on other ports than the normal HTTP
port 80 and HTTPS port 443; so the Internet infrastructure that was built up around those specific ports (fire-
walls, proxies, and so on) needed updating to allow all web browsers and servers, many of which might be
behind a household or corporate firewall that limits access to nonstandard ports.
In 2009, the WebSocket specification ( www.w3.org/TR/websockets ) was proposed as a solution to the lack
of permanent sockets in the browser and the port problem. The idea behind WebSockets is to upgrade a standard
HTTP socket into a WebSocket using a handshake technique that both the server and client need to understand.
That socket is then kept open and allows bidirectional, full-duplex communication between the client and serv-
er.
The capability to use WebSockets in HTML5 applications was a bit slow in coming. The primary reason for
this is that there has been an evolution of the specification, which means that different browsers support dif-
ferent versions of the spec, and some security issues related to cache positioning of proxies caused WebSocket
support to be removed from Firefox until the issue was fixed.
The good news is that the issue has now been fixed, and all current-generation browsers except IE9 have
some version of WebSockets turned on. The bad news is that because of proxies, caches, and IE9, you can't use
standard WebSockets without support for some fallback. For this reason, in lieu of using straight WebSockets,
this chapter spends the most time covering a Node.js library called Socket.io that provides a consistent client
and server API regardless of whether native WebSockets or one of the supported fallback mechanisms are sup-
ported.
Using Native WebSockets in the Browser
The native WebSocket API available in supported browsers is quite small and clean, but it doesn't do a lot other
than send text to and from the server, so the addition of compatibility and fallback issues make it a chore to
work with directly.
Assuming you have a server that supports WebSockets, you can open a connection using a new WebSocket
object from the browser with the following:
var socket = new WebSocket("ws://servername.com/socket-resource");
The WebSocket equivalent of the http:// URL prefix is ws:// . Secure WebSockets, the equivalent of
https:// , has a wss:// prefix.
That socket object has four callbacks used to listen for events on the socket:
socket.onopen = function(){
// Socket has been opened
};
socket.onmessage = function(event) {
// Message data in event.data
};
Search WWH ::




Custom Search