In this chapter, we will cover the following topics:
- Introduction to WebSockets
- Actor Model and Akka Actors
- WebSockets in Play: using Iteratees and Actors
- FrameFormatters
Picture this:
A moviegoer is trying to purchase movie tickets online. He or she has selected the seats, entered the payment details, and submitted. He or she gets an error message saying that the tickets they tried to book have sold out.
Consider an application, which gives detailed information about the stock market and allows purchasing/selling stocks. When someone enters payment details and submits these details, they get an error saying that the purchase has been rejected as the price of the stock has now changed.
Initially, in applications where real-time data was required over HTTP, developers realized that they needed bidirectional communication between the client side and server side. It was generally implemented using one of the following approaches:
- Polling: Requests are sent from the client side at fixed and regular intervals. The server responds within a short span (less than 1 second or so) with a result for each request made.
- Long-polling: When a request is sent, the server does not respond with a result unless there has been a change in the state within a specified time period. A request is fired after a response is received from the server. Therefore, the client side makes repeated requests as and when it gets the response for the previous one.
- Streaming: A request to the server results in an open response, which is continuously updated and kept open indefinitely.
Although these approaches worked, using them led to some problems:
- It led to an increase in the number of TCP connections per client
- There was a high overhead of HTTP Header Overhead while mapping a response to its corresponding request on the client side
In 2011, a protocol that uses a single TCP connection for bidirectional traffic, WebSocket (RFC6455), was standardized by the Internet Engineering Task Force (IETF). By September 20, 2012, the World Wide Web Consortium (W3C) came up with the specifications for a WebSocket API.
Unlike HTTP, there is no request-response cycle in a WebSocket. Once connected, the client and server can send messages to each other. The communication can be by server and by client, that is, a two-way full duplex communication.
According to the WebSocket API:
- A WebSocket connection can be established by invoking the constructor, such as
WebSocket(url, protocols) - Data can be sent to the server via a connection using the
send(data)method - Calling
close()will result in closing the connection - The following event handlers can be defined on the client side:
onopenonmessageonerroronclose
A snippet using JavaScript is shown here:
var webSocket = new WebSocket('ws://localhost:9000'),
webSocket.onopen = function () {
webSocket.send("hello");
};
webSocket.onmessage = function (event) {
console.log(event.data);
};
webSocket.onclose = function () {
alert("oops!! Disconnected")
}