The Web Messaging Problem

Traditionally, the web servers deliver data using a request/response model as follows:

  1. The user opens a web page in the web browser
  2. The web browser makes an HTTP request to the web server and displays the content of the web page as it is available on the web server at the moment of the request
  3. If after the web page is displayed, the content of the page changes, then the user will not see the changes until the user manually refreshes the web page in the browser

A technique named HTTP polling is often used to provide users with up-to-date content without the need for the manual refresh of Step 3 above, thus achieving a form of web messaging. The polling technique consists of including some JavaScript code in the web page which is executed by the web browser in background as long as the web page is displayed by the browser. The script periodically sends HTTP requests to the web server to check whether or not there are changes in the content of the web page. If there are no changes, the script will do nothing, otherwise it will display the new content.

While the HTTP polling technique can be used to achieve a rudimentary form of web messaging for certain applications, this technique becomes highly inefficient for many other web applications, especially for those with a high number of users and expecting low data latency, near to the real-time.

Indeed, even if the polling script is configured to poll the web server as frequently as a web server can handle, the latency of data - i.e. the time required to propagate the data from the server side to the user can still be too high for web applications such as a financial portal delivering real-time market data or a sports betting website where each millisecond counts.

Also, given that the web servers have substantial limitations in handling a high number of concurrent users which perform a high number of HTTP requests per second, a real-time web application with a large number of users, say of the order of millions, would need a lot of web servers to achieve web messaging through HTTP polling. Moreover, each HTTP request sent by the polling script, just to check whether there is or not any fresh data on the server, includes hundreds of bytes, which are automatically added by the browser to each request as the HTTP headers. This redundant overhead sent by many users at a high polling frequency produces an important bandwidth consumption. The need for many server machines for the web server and the high network utilization due to the overhead of the HTTP headers significantly increase the total cost of ownership for the applications with many concurrent users when using the HTTP polling technique to deliver real-time data.

MigratoryData's Solution

The MigratoryData server delivers data according to a publish/subscribe model as follows:

  1. The user sends a subscription request to the server
  2. A persistent TCP connection is created between the user's browser and the MigratoryData server
  3. The MigratoryData server uses this persistent TCP connection to deliver data available at the moment of the request, as well as any subsequent data as soon as such data is available, and without any additional requests from the user

MigratoryData implements the WebSockets protocol (see the standard). Currently all major browsers have support for WebSockets. MigratoryData creates the TCP streaming connection described at Step 2 above using WebSockets. For the legacy browsers without support for WebSockets, MigratoryData implements techniques which still use a single TCP connection for streaming – like WebSockets do behind the scene – and it's 100% JavaScript-based, no browser plug-in being required.

MigratoryData Server was designed to scale to a huge number of concurrent users. MigratoryData set a new standard in scalability, which is the ability to handle 10 million concurrent users on a single 1U server (with substantial messaging traffic, of the order of 1 Gbps).

The proposal that MigratoryData offers to resolve this is not only a very scalable messaging solution for adding real-time functionalities to web applications, it also achieves high scalability without sacrificing reliability as detailed in the paper (the final version of this paper is available in the proceedings of the 18th ACM/IFIP/USENIX Middleware International Conference from ).

The MigratoryData Client API for JavaScript for building very scalable and reliable real-time web applications is also available for other technologies. You can use the same MigratoryData Client API to build real-time mobile applications for iOS and Android, as well as other real-time Internet applications written in Java, .NET, C++, NodeJS, Python, and PHP.

MigratoryData is a proven web messaging solution that has been used for over a decade and continues to successfully deliver real-time data to millions of users every day.