The Web Messaging Problem
Traditionally, the web servers deliver data using a request/response model as follows:
- The user opens a web page in the web browser
- 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
- 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
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.
The MigratoryData server delivers data according to a publish/subscribe model as follows:
- The user sends a subscription request to the server
- A persistent TCP connection is created between the user's browser and the MigratoryData server
- 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
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 ).
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.