Comet, Pub Sub, ActionCable

Comet, Pub Sub, ActionCable

Comet and Pub/Sub and their implementations in the Rails ActionCable framework.

Comet

Comet is a technology (a web application model) that allows sending data to he client without any requests from the client side. The server decides when and what data it wants to transfer to the client. Alternative name of this technology is Push technology, in contrast to the Pull technology like Ajax, which, in turn, pulls data from the server (unlike Comet, where the server pushes data to the client).

Comet:

Is a Push technology

Allows to send data to the client without requests frolm the client

Works in the real time

Comet vs Ajax

The naming history of Comet: Comet is #2 most popular cleanser in the US (after Ajax).

Comet: data travels from the server to the client only

Ajax: the client sends a request, the server responds to the request

Publish/Subscribe (Pub/Sub) technology:

is a client-server interaction model via Comet technology

the Server provides named channels

the Client subscribes to one or more channels

the Server sends data (message) to the channel

All clients subscribed to the channel receive the message

Pub/Sub is a specific model of the Comet client-server interaction technology. Comet only means that we send data to the client without any request (that this is a Push technology). Pub/Sub is a specific implementation of this approach. Generally Pub/Sub is based on the following ideas:

the Server provides named channels (channel A, channel B, etc) — communication channels which it uses to send data. The client can subscribe to one or more channels. The server knows nothing about clients, it simply passes the data to the channel, and customers that are connected to these channels receive messages (data sent through the channels iscalled messages).

Historical technologies — Pub/Sub predecessors

Comet and Pub/Sub both have ququite a long history, taking roots in technologies that were used 5-10 years back. First of all, they were based on Flash. Currently Flash is getting abandoned and are gradually disappearing from the browser, but they served as the first attempts to implement Comet principles in the browser using either flash sockets or RTMP Protocol supported by Adobe’s flash media server, which were usually used for video streaming and conferences.

Pub/Sub historical predecessors:

Flash technologies (FlashSocket, RTMP)

Short Polling

Infinite iframe

Short Polling is very much like Ajax, but in this case the client continuously requests data, while the server only stores the message history for a particular client and returns them to him if they appear in the queue. It can’t be called a fully Comet-technology, because the client still makes the reques.

Infinite iframe is quite an insteresting historical version of Comet: a page contains an iframe, and we can transfer data from the internal frame to the parent using js. The iframe is given to the server indefinitely long and the server doesn’t shut up (didn’t stop transferring of the body of the page), and just keeps adding new lines there with the implementation of some js, which, in turn, is sending a message to the parent window. Now this approach (as well as other historical technologies) is not used anymore because there are more modern alternatives.

Modern Comet Technologies

Long Polling

Server Sent Events

WebSockets

Long Polling — like with Short Polling, the interaction in this case is also partly initiated on the client side (the client makes a request), but the server doesn’t respond immediately. It rather keeps the connection open for some time and if this period of time you need to send a message to the client (ie an event occurs), then it sends the response back to the client, and if it doesn’t, it waits for a certain time (timeout) after which the client re-sends the request and waits again.

Server Sent Events is a fairly new technology, using an HTML 5 standard, which allows the client to send a request 1 time (usually a GET request) to some page (to any address on the server) and then the server can work with this request for an arbitrarily long time and send its data via this connection. Partly it resemples an infinite iframe, but done properly.

Let’s look at these 3 technologies in more detail.

Long Polling
Server-client interaction sheme of the Long Polling technology:

Case 1: the client makes a request (usually a GET request) to the poll address, and it doesn’t get a response until an event occurs on the server. Once an event occured, that needs to be sent to the client, the server sends a response, after which the clinet immediately makes a new poll-request and waits again.

Case 2: no event occurs, but the time ran out (timeout occured). The timeout time can be tweaked, usually it is set to not more than 1 minute. In the case of tieout the client recieves an empty resqonse and a new request to poll starts. Disqus is a good example of Long Polling. If you open a web console, you;ll see constant poll requests with constant answers with data to them (for instanc, that you have a new private message that you received a reply to your comment in the thread.

Server Sent Events

Here, too, the client makes a 1-time request as well, typically GET (in fact, it initiates/opens a channel), then, if there is a need to send data to the client, the server sends data via this open connection. In fact, a connection is initiated, and then the server uses it to send messages based on events. The technology is very simple to implement, for example in terms of Rails, it is a separate controller and 1 action, which you can use to do whatever ou want: send data to the client, etc. But this technology has one big disadvantage: it is generally not supported by the Internet Explorer (even its recent versions). That is why it is rarely used (Explorer sitting on quite a lot of people, and you’ll have to use a different technology for them, but why use 2 technoligies while you can use 1 which supports everyhing).

WebSockets
This technology involves opening a connection to the server (the server sends a connection request, if the server is ready it sends a response with a status of open (i.e. opens the connection). Then this connection is used to send messages back and forth in any direction, in any order, asynchronously (there is no relation between the messages going in one or the other side). WebSockets is a technology of a two-way communication between the client and the server: 1 connection is used to send data in both directions and the server can process messages from the client. WebSockets can be used instead of Ajax, but it will be difficult in terms of crafting client-side and server-side logic, although such experiments do exist — for example, WebSocket, REST.

Implementations and libraries

Some particular implementations and libraries of the 3 technologies we discussed above:

Faye There are implementations on Ruby and Node.js. For Rails there is PrivatePub that enables comfortable integration a web socket into your app. It supports both web sockets and long polling.

ActionCable allows to work with web sockets only (this is a disadvantage since not all browsers support them, for instance Explorer does so only from the version 10).

PaaS When you buy a subscripion to such a service, it takes care of the real time interaction part of your app by provoding an API and client scripts. Normally they use web sockts and have callbacks for long polling. Pusher.io is the most well-known PaaS solution, there are also less popular pubnub and ably.

ActionCable

For the Rails app it makes sense to use ActionCable:

Built-in Rails 5+ framework

Channels = access to app’s business logic

Streams are an implementation of pub/sub

Possibility of client-server message exchange via cable

ActionCable is a built-in Rails framework (from Rails 5). After rails new you have everything you need to start using ActionCable. It has several primary elements, like channels. Channels are not something like Pub/Sub channels via which messages travel, they are more like controllers for web sockets, describing their business logic. You can restrict access to the channels (parts of your business logic) to implement subscritions to channels (that are a part of the Pub/Sub logic). Essentially, stream is a named channel. Clients can subscribe to channels and recieve messages from them.