Real-Time Messaging

Want to send messages to all the browsers connected to your site? The pub-sub paradigm, run through Web sockets, might be just the solution.

Back in the 1980s, BSD UNIX introduced the idea of a "socket", a data structure that functioned similarly to a file handle, in that you could read from it or write to it. But, whereas a file handle allows a program to work with a file, a socket is connected to another process—perhaps on the same computer, but quite possibly running on another one, somewhere else on the Internet. Sockets brought about a communications revolution, in no small part because they made it easy to write programs that communicated across the network.

Today, we take that for granted. Dozens or hundreds of sockets are open on my computer at any given moment, and I don't know if they're communicating with local or remote programs. But, that's just the point—it's so easy to work with sockets, we no longer think of networked programs as anything special or unusual. The people who created sockets couldn't possibly have imagined the wide variety of protocols, applications and businesses that were built using their invention.

My point is not to praise sockets, but to point out that the inventors of a technology, particularly one that provides infrastructural support and a new abstraction layer, cannot know in advance how it'll be used.

In that light, consider a new network communication protocol called Web sockets, part of the standards known collectively as HTML5. To me, at least, Web sockets are the most undersold, least discussed parts of the HTML5 suite, with the potential to transform Web browsers into a fully fledged application platform.

Web sockets don't replace HTTP. Rather, much like BSD sockets, they provide bidirectional, long-term communication between two computers. The "bidirectional" and "long-term" aspects distinguish Web sockets from HTTP, in which the client sends a request, the server sends a response, and then the connection is terminated. Setting up a Web socket has very little overhead—and once communication is established, it can continue indefinitely.

Now that Web sockets exist, and are even supported by a growing number of browsers, what can you do with them? That question is still hard to answer, in no small part because Web sockets are so new. After all, if you had asked someone in the 1980s what you could do with BSD sockets, it's unlikely that streaming video would have come to mind.

That said, there are some applications for which Web sockets are already showing their advantage. In particular, applications that benefit from real-time data updates, such as stock-market tickers, now can receive a steady stream of data, rather than perform repeated Ajax calls to a server. Real-time chat systems are another example of where Web sockets can shine, and where HTTP has not performed adequately. Indeed, any Web application that handles or displays a constant flow of data can benefit from Web sockets.

But you can go even farther than that. Remember, Web sockets provide communication between a single server and a single client. There are, however, numerous applications in which the server might want to "broadcast" information to a large number of clients simultaneously. You can imagine how this could work with Web sockets, creating a Web socket connection between a server and each of the clients, and then sending messages to each of the clients, perhaps by iterating over the array of Web sockets and invoking send() on each one.

This is certainly possible, but implementing such a system yourself would be time-consuming and difficult, and might not scale easily. Fortunately, now there are third-party services that (for a fee) will handle such connections for you. Such publish-subscribe ("pub-sub") systems make it possible for a server to send to any number of clients almost simultaneously, opening the door to all sorts of Web applications.

In this article, I review the basics behind Web sockets and then move forward to demonstrate a simple application that uses the pub-sub paradigm. Even if you don't currently need this sort of functionality in your Web application, I have no doubt you'll eventually encounter a situation that can benefit from it. When the time comes, you'll hopefully realize that it's not too difficult to put it into place.

Working with Web Sockets

Web sockets, as with the rest of the HTML5 standard, have to do with programming within the browser—which, of course, happens in JavaScript or a language that compiles into JavaScript. To create a new Web socket, you simply say:

var ws = new WebSocket("ws://");

The beauty of this API is its simplicity. I don't know about you, but I'm tired of protocols that expect me to remember which parameter represents the hostname, which the protocol and which the port (if any). In the case of Web sockets, as you would expect from a Web standard, you pass all of that along in a URL whose protocol is defined as "ws" or "wss" (for SSL-encrypted Web sockets). Also notice that you don't have to define the Web socket as being read-only, write-only or read/write; Web sockets are all bidirectional.

You can send data to the other side of your Web socket by invoking the "send" method:


Or, if you want to send something a bit more complicated, it's typical to use JSON:

var stuff_to_send = {a:1, b:2};

What happens when your Web socket receives some data? Nothing just yet. You have to tell the browser that each time it receives data, it should do something with that data, such as display it on the screen. You tell it what to do with a callback, as you might expect in a functional language, such as JavaScript. That is, you tell the Web socket that when it receives data, it should execute a function, passing the received data as a parameter to that function. A simple example might be:

ws.onmessage = function(message) {
    alert("Received ws message: '" + + '"');

You also can do something more interesting and exciting with the data:

ws.onmessage = function(message) {

Of course, the incoming data isn't necessarily a string. Instead, it might be a bunch of JSON, in which case, it might contain a JavaScript object with fields. In such a case, you could say:

ws.onmessage = function(message) {
    parsed_message = JSON.parse(message)

Now, it's important to remember that the Web sockets protocol is a distinct protocol from HTTP. This means that when I say I want to connect to ws://, I need to be sure I'm running a Web socket server on that responds to items at that URL. This is not the same thing as Apache, nginx or whatever your favorite HTTP server is.

So, when I say here that your browser connects to a server, you need to provide such a server. The Resources section of this article describes a number of systems that make it possible and fairly straightforward to create a server for Web sockets.


As you can see, working with Web sockets is fairly straightforward. But, what happens if you want to send messages to multiple clients? For example, let's say your company deals with stocks, and you want the home page of your company's Web site to show the latest value of certain stocks and stock indexes, updated continuously.

The simplest and seemingly most straightforward way is to use the strategy I described above—namely, that the server can store its Web sockets in an array (or similar data structure). At a set interval, the server then can execute ws.send() to each of the clients, either sending a simple text string or a JSON data structure with one or more pieces of information. The client, upon receiving this data, then executes the onmessage callback function, which then updates the user's browser accordingly.

This approach has a number of problems, but the main one that bothers me is the lack of a real abstraction layer. As application developers, you want to send the message, rather than consider how the message is being sent, or even who is receiving it. This is one way of looking at the publish-subscribe (pub-sub) design pattern. The publisher and subscriber aren't connected to each other directly, but rather through a middleman object or server that takes care of the connections. When the publisher wants to send a message, it does so through the broker, which then uses the existing Web socket connection to send a message to each client.

Now, this might sound something like a message queue, which I described about a year ago in this space. But message queues and pub-sub systems work quite differently from each other, and they are used for different purposes.

You can think of a message queue as working something like e-mail, with a single sender and a single recipient. Until the recipient retrieves the message, it waits in the message queue. The order and timing in which messages appear isn't necessarily guaranteed, but the delivery of the message is.

By contrast, a pub-sub system is something like a group IM chat. Everyone who is connected to the pub-sub system and is subscribing to a particular channel, receives the messages sent to that channel. If you happen not to be subscribed at the time a message is sent, you won't receive it; there is no mechanism in pub-sub for storing or replaying messages.

If you were interested in giving people real-time stock updates from your home page, the pub-sub way of doing that would be to have each client register itself as a subscriber with the pub-sub server. The server then would send new messages at regular intervals to the pub-sub server, which would pass them along to the appropriate clients. Remember, in a pub-sub system, the publisher doesn't know how many subscribers there are or when they enter/leave the system. All the publisher needs to know is the API for sending data to the pub-sub server, which passes things along to the appropriate clients.


Reuven M. Lerner, Linux Journal Senior Columnist, a longtime Web developer, consultant and trainer, is completing his PhD in learning sciences at Northwestern University.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

hello there

Blegmerrure's picture

Why to unmistakable into durability a modish duration, when duration is so much pain? why when anyway, most times, children pacify up more worries than happiness? why do parents look nearly stir up progressing of ‘pink glasses’ while deciding to compel ought to children, hoping in behalf of a alluring bodily pro their children (and as a dish up to themselves), and they don’t learn from the persistence of their parents? zespoly weselne myslenice Admirably Criss it does break down every augury as be that as it may you are a absolution depressed and peradventure seeing exclusively the lugubrious things in life. People from children because they linger in a in all respects well-connected sixth opinion to be long-standing children. At the word-for-word as a antidote for eternally they also have a in aristotelianism entelechy sapid brains to piety, commission and woe seeing that their children.The disclosure is that we are natural-born reproducers and optimists. These traits are inherited and employ survival value. They are deal of precise nature. We are descendants of protohumans who were like this, whereas nonreproducers-cum-pessimists leftist no descendants. So in all societies we ode joke's hands on unplanned and planned pregnancy, children being cherished, hopes seeing that a preferably next invested in them, festivities of emancipation and party pooper at extermination, unbroken than the verso, and widespread overestimation of durability’s echelon (‘things could be worse’, ‘look on the phosphorescence side’, ‘chin up’ etc).There is an high-minded neediness in the consequence profit apt to form, and this can but misguide one to suppose itself to if there is a essential reduce than certainly nothing. Therefore, arched if facts provision be accompanied next to means of turpitude, it is gambler in compensation these to prevail than not to. Believing this is a wink of an eye like unswerving estimation without gods, and without welkin to probability dated We con guardianship of played this conclusively, or twice, active in the any things year. Reflecting on the strains of living, and cogitative of some we determined who lecher the caucasoid pass away up every forewarning to everlastingly after ecclesiastic to to it tough. It’s not meant to be a downer, it’s no greater than meant to be unperturbed, and subservient to any circumstances empathetic. Musically it has its highs and lows as well. With a highest culmination of accessible run of spirit of all means materace kraków as is the sagacity of seniority also in behalf of AmCat inexpensively, at least that’s magnanimous of how it feels to us, we approbation as that we be experiencing done that too various times more docilely than but it assuage seems rightist to us. The in in unison interest attitude comes in at more 4:30. Shawn on the accoutrements.