From the course: WebSocket Programming with Java EE

Rise of WebSocket

From the course: WebSocket Programming with Java EE

Start my 1-month free trial

Rise of WebSocket

- [Instructor] The rise of WebSocket came very quickly after they were first introduced. Front- and back-end developers saw their potential for improving the user experience and took advantage. However, the web wasn't built to be dynamic. The HTML language was designed to deliver static pages by linking directly from one page to another. Although it wasn't long before the needs of web users changed, and developers wanted ways to make their experience more user-friendly through the use of dynamically changing content, which would deliver a much richer user experience. Developers attempted to provide this by manipulating and hacking the limitations of HTML and JavaScript, and it was largely successful, although many of the hacks they used were slow and inefficient. Let's examine a few of the established techniques that became popular for delivering dynamic content in the pre Socket environment. A technique that allowed content to be loaded into the current page, which gives the impression of an application style experience was developed through cross-frame communication. This worked by loading a new page from a server into a frame, and then retrieving data from that page. This could be done without reloading the current page giving the impression that the data was loaded directly from the server. Similar to cross-frame communication, the polling technique makes periodic requests to the server for data. It does this regardless of whether there is new data or not, and a new connection is made for each request. It is easy to see how this is very inefficient and makes the web page very chatty. An improvement on this technique is long polling. The client establishes a connection to the server and holds the connection open until it is closed. The server sends data to the client when there is new data available, simulating a server push type feature. The advantages over simple polling are that data is sent only when it is necessary, therefore using server and client resources more efficiently. It performs well with low traffic, but can be prone to latency issues at the high processing levels. Another common solution, and arguably the predecessor of WebSocket, is Ajax. A connection is made to the server via JavaScript only when data is required by the site, and the server responds with the requested data. The main feature of Ajax is that it is nonblocking, meaning that the user does not have to wait for the response and can continue using the site. When a response is received by the client, a callback method is executed and passes the response data. Typical examples of Ajax in action would be autocompleting drop-downs and news tickers, which no doubt you have seen plenty of. This is a great solution and has been used very effectively for many years, but suffers from one major drawback, which is that it's behavior when moving high volumes of data creates bottlenecks. We have looked at some of the most popular solutions for providing real-time bidirectional communications between server and client, and they have served us well for much of the last decade or longer, but they suffer from the same main issues. They are very resource intensive and use those resources inefficiently. This may occur on either the client, where data has to be moved and processed, or on the server side, where unnecessary requests are made for data. All techniques use the HTTP protocol, which is a text-based protocol that sends complete headers with each request and response. This makes each communication large and inefficient. Except for Ajax, these solutions are really just workarounds that overcome the limitations of HTTP and browsers. Wherever you see a hack, you've got to think that there's an inadequacy in the technology that needs to be addressed And most importantly, the communication is not fully duplexed, it is only half duplex, which means that one end of the communication must wait for the other end to finish before it can act. All of these issues go away with WebSocket. The WebSocket protocol is lightweight, bidirectional, and provides a fully duplexed communication channel that is supported by all modern browsers. It is relatively simple to implement and specifically designed to solve the problems we have just been discussing.

Contents