WebSockets – Useful Resources ”; Previous Next The following resources contain additional information on WebSockets. Please use them to get more in-depth knowledge on this. Useful Video Courses Network Socket programming in C Practical Way 8 Lectures 1.5 hours Musab Zayadneh More Detail CompTIA A+ Certification Training: Core 1 (220-1001) Best Seller 133 Lectures 17.5 hours Total Seminars More Detail The RedTeam Blueprint – A Unique Guide To Ethical Hacking Featured 267 Lectures 30 hours Brandon Dennis More Detail Web Application Hacking with Burp Suite 16 Lectures 2 hours Scott Cosentino More Detail Network sockets and streaming (C# based) 17 Lectures 1.5 hours Taurius Litvinavicius More Detail Blazor in 2020 28 Lectures 2.5 hours Taurius Litvinavicius More Detail Print Page Previous Next Advertisements ”;
Category: websockets
WebSockets – Handling Errors
WebSockets – Handling Errors ”; Previous Next Once a connection has been established between the client and the server, an open event is fired from the Web Socket instance. Error are generated for mistakes, which take place during the communication. It is marked with the help of onerror event. Onerror is always followed by termination of connection. The onerror event is fired when something wrong occurs between the communications. The event onerror is followed by a connection termination, which is a close event. A good practice is to always inform the user about the unexpected error and try to reconnect them. socket.onclose = function(event) { console.log(“Error occurred.”); // Inform the user about the error. var label = document.getElementById(“status-label”); label.innerHTML = “Error: ” + event; } When it comes to error handling, you have to consider both internal and external parameters. Internal parameters include errors that can be generated because of the bugs in your code, or unexpected user behavior. External errors have nothing to do with the application; rather, they are related to parameters, which cannot be controlled. The most important one is the network connectivity. Any interactive bidirectional web application requires, well, an active Internet connection. Checking Network Availability Imagine that your users are enjoying your web app, when suddenly the network connection becomes unresponsive in the middle of their task. In modern native desktop and mobile applications, it is a common task to check for network availability. The most common way of doing so is simply making an HTTP request to a website that is supposed to be up (for example, http://www.google.com). If the request succeeds, the desktop or mobile device knows there is active connectivity. Similarly, HTML has XMLHttpRequest for determining network availability. HTML5, though, made it even easier and introduced a way to check whether the browser can accept web responses. This is achieved via the navigator object − if (navigator.onLine) { alert(“You are Online”); }else { alert(“You are Offline”); } Offline mode means that either the device is not connected or the user has selected the offline mode from browser toolbar. Here is how to inform the user that the network is not available and try to reconnect when a WebSocket close event occurs − socket.onclose = function (event) { // Connection closed. // Firstly, check the reason. if (event.code != 1000) { // Error code 1000 means that the connection was closed normally. // Try to reconnect. if (!navigator.onLine) { alert(“You are offline. Please connect to the Internet and try again.”); } } } Demo for receiving error messages The following program explains how to show error messages using Web Sockets − <!DOCTYPE html> <html> <meta charset = “utf-8” /> <title>WebSocket Test</title> <script language = “javascript” type = “text/javascript”> var wsUri = “ws://echo.websocket.org/”; var output; function init() { output = document.getElementById(“output”); testWebSocket(); } function testWebSocket() { websocket = new WebSocket(wsUri); websocket.onopen = function(evt) { onOpen(evt) }; websocket.onclose = function(evt) { onClose(evt) }; websocket.onerror = function(evt) { onError(evt) }; } function onOpen(evt) { writeToScreen(“CONNECTED”); doSend(“WebSocket rocks”); } function onClose(evt) { writeToScreen(“DISCONNECTED”); } function onError(evt) { writeToScreen(”<span style = “color: red;”>ERROR:</span> ” + evt.data); } function doSend(message) { writeToScreen(“SENT: ” + message); websocket.send(message); } function writeToScreen(message) { var pre = document.createElement(“p”); pre.style.wordWrap = “break-word”; pre.innerHTML = message; output.appendChild(pre); } window.addEventListener(“load”, init, false); </script> <h2>WebSocket Test</h2> <div id = “output”></div> </html> The output is as follows − Print Page Previous Next Advertisements ”;
WebSockets – Events & Actions ”; Previous Next It is necessary to initialize the connection to the server from client for communication between them. For initializing the connection, creation of Javascript object with the URL with the remote or local server is required. var socket = new WebSocket(“ ws://echo.websocket.org ”); The URL mentioned above is a public address that can be used for testing and experiments. The websocket.org server is always up and when it receives the message and sends it back to the client. This is the most important step to ensure that application works correctly. Web Sockets – Events There are four main Web Socket API events − Open Message Close Error Each of the events are handled by implementing the functions like onopen, onmessage, onclose and onerror functions respectively. It can also be implemented with the help of addEventListener method. The brief overview of the events and functions are described as follows − Open Once the connection has been established between the client and the server, the open event is fired from Web Socket instance. It is called as the initial handshake between client and server. The event, which is raised once the connection is established, is called onopen. Message Message event happens usually when the server sends some data. Messages sent by the server to the client can include plain text messages, binary data or images. Whenever the data is sent, the onmessage function is fired. Close Close event marks the end of the communication between server and the client. Closing the connection is possible with the help of onclose event. After marking the end of communication with the help of onclose event, no messages can be further transferred between the server and the client. Closing the event can happen due to poor connectivity as well. Error Error marks for some mistake, which happens during the communication. It is marked with the help of onerror event. Onerror is always followed by termination of connection. The detailed description of each and every event is discussed in further chapters. Web Sockets – Actions Events are usually triggered when something happens. On the other hand, actions are taken when a user wants something to happen. Actions are made by explicit calls using functions by users. The Web Socket protocol supports two main actions, namely − send( ) close( ) send ( ) This action is usually preferred for some communication with the server, which includes sending messages, which includes text files, binary data or images. A chat message, which is sent with the help of send() action, is as follows − // get text view and button for submitting the message var textsend = document.getElementById(“text-view”); var submitMsg = document.getElementById(“tsend-button”); //Handling the click event submitMsg.onclick = function ( ) { // Send the data socket.send( textsend.value); } Note − Sending the messages is only possible if the connection is open. close ( ) This method stands for goodbye handshake. It terminates the connection completely and no data can be transferred until the connection is re-established. var textsend = document.getElementById(“text-view”); var buttonStop = document.getElementById(“stop-button”); //Handling the click event buttonStop.onclick = function ( ) { // Close the connection if open if (socket.readyState === WebSocket.OPEN){ socket.close( ); } } It is also possible to close the connection deliberately with the help of following code snippet − socket.close(1000,”Deliberate Connection”); Print Page Previous Next Advertisements ”;
WebSockets – Security
WebSockets – Security ”; Previous Next Protocol should be designed for security reasons. WebSocket is a brand-new protocol and not all web browsers implement it correctly. For example, some of them still allow the mix of HTTP and WS, although the specification implies the opposite. In this chapter, we will discuss a few common security attacks that a user should be aware of. Denial of Service Denial of Service (DoS) attacks attempt to make a machine or network resource unavailable to the users that request it. Suppose someone makes an infinite number of requests to a web server with no or tiny time intervals. The server is not able to handle each connection and will either stop responding or will keep responding too slowly. This can be termed as Denial of service attack. Denial of service is very frustrating for the end users, who could not even load a web page. DoS attack can even apply on peer-to-peer communications, forcing the clients of a P2P network to concurrently connect to the victim web server. Man-in-the-middle Let us understand this with the help of an example. Suppose a person A is chatting with his friend B via an IM client. Some third person wants to view the messages you exchange. So, he makes an independent connections with both the persons. He also sends messages to person A and his friend B, as an invisible intermediate to your communication. This is known as a man-in-the-middle attack. The man-in-the-middle kind of attack is easier for unencrypted connections, as the intruder can read the packages directly. When the connection is encrypted, the information has to be decrypted by the attacker, which might be way too difficult. From a technical aspect, the attacker intercepts a public-key message exchange and sends the message while replacing the requested key with his own. Obviously, a solid strategy to make the attacker”s job difficult is to use SSH with WebSockets. Mostly when exchanging critical data, prefer the WSS secure connection instead of the unencrypted WS. XSS Cross-site scripting (XSS) is a vulnerability that enables attackers to inject client-side scripts into web pages or applications. An attacker can send HTML or Javascript code using your application hubs and let this code be executed on the clients” machines. WebSocket Native Defense Mechanisms By default, the WebSocket protocol is designed to be secure. In the real world, the user might encounter various issues that might occur due to poor browser implementation. As time goes by, browser vendors fix any issues immediately. An extra layer of security is added when secure WebSocket connection over SSH (or TLS) is used. In the WebSocket world, the main concern is about the performance of a secure connection. Although there is still an extra TLS layer on top, the protocol itself contains optimizations for this kind of use, furthermore, WSS works more sleekly through proxies. Client-to-Server masking Every message transmitted between a WebSocket server and a WebSocket client contains a specific key, named masking key, which allows any WebSocket-compliant intermediaries to unmask and inspect the message. If the intermediary is not WebSocket-compliant, then the message cannot be affected. The browser that implements the WebSocket protocol handles masking. Security Toolbox Finally, useful tools can be presented to investigate the flow of information between your WebSocket clients and server, analyze the exchanged data, and identify possible risks. Browser Developer Tools Chrome, Firefox, and Opera are great browsers in terms of developer support. Their built-in tools help us determine almost any aspect of client-side interactions and resources. It plays a great role for security purposes. Print Page Previous Next Advertisements ”;
WebSockets – Quick Guide
WebSockets – Quick Guide ”; Previous Next WebSockets – Overview In literal terms, handshaking can be defined as gripping and shaking of right hands by two individuals, as to symbolize greeting, congratulations, agreement or farewell. In computer science, handshaking is a process that ensures the server is in sync with its clients. Handshaking is the basic concept of Web Socket protocol. The following diagram shows the server handshake with various clients − Web Sockets – Definition Web sockets are defined as a two-way communication between the servers and the clients, which mean both the parties communicate and exchange data at the same time. The key points of Web Sockets are true concurrency and optimization of performance, resulting in more responsive and rich web applications. Description of Web Socket Protocol This protocol defines a full duplex communication from the ground up. Web sockets take a step forward in bringing desktop rich functionalities to the web browsers. It represents an evolution, which was awaited for a long time in client/server web technology. The main features of web sockets are as follows − Web socket protocol is being standardized, which means real time communication between web servers and clients is possible with the help of this protocol. Web sockets are transforming to cross platform standard for real time communication between a client and the server. This standard enables new kind of the applications. Businesses for real time web application can speed up with the help of this technology. The biggest advantage of Web Socket is it provides a two-way communication (full duplex) over a single TCP connection. URL HTTP has its own set of schemas such as http and https. Web socket protocol also has similar schema defined in its URL pattern. The following image shows the Web Socket URL in tokens. Browser Support The latest specification of Web Socket protocol is defined as RFC 6455 – a proposed standard. RFC 6455 is supported by various browsers like Internet Explorer, Mozilla Firefox, Google Chrome, Safari, and Opera. WebSockets – Duplex Communication Before diving to the need of Web sockets, it is necessary to have a look at the existing techniques, which are used for duplex communication between the server and the client. They are as follows − Polling Long Polling Streaming Postback and AJAX HTML5 Polling Polling can be defined as a method, which performs periodic requests regardless of the data that exists in the transmission. The periodic requests are sent in a synchronous way. The client makes a periodic request in a specified time interval to the Server. The response of the server includes available data or some warning message in it. Long Polling Long polling, as the name suggests, includes similar technique like polling. The client and the server keep the connection active until some data is fetched or timeout occurs. If the connection is lost due to some reasons, the client can start over and perform sequential request. Long polling is nothing but performance improvement over polling process, but constant requests may slow down the process. Streaming It is considered as the best option for real-time data transmission. The server keeps the connection open and active with the client until and unless the required data is being fetched. In this case, the connection is said to be open indefinitely. Streaming includes HTTP headers which increases the file size, increasing delay. This can be considered as a major drawback. AJAX AJAX is based on Javascript”s XmlHttpRequest Object. It is an abbreviated form of Asynchronous Javascript and XML. XmlHttpRequest Object allows execution of the Javascript without reloading the complete web page. AJAX sends and receives only a portion of the web page. The code snippet of AJAX call with XmlHttpRequest Object is as follows − var xhttp; if (window.XMLHttpRequest) { xhttp = new XMLHttpRequest(); } else { // code for IE6, IE5 xhttp = new ActiveXObject(“Microsoft.XMLHTTP”); } The major drawbacks of AJAX in comparison with Web Sockets are − They send HTTP headers, which makes total size larger. The communication is half-duplex. The web server consumes more resources. HTML5 HTML5 is a robust framework for developing and designing web applications. The main pillars include Mark-up, CSS3 and Javascript APIs together. The following diagram shows HTML5 components − The code snippet given below describes the declaration of HTML5 and its doctype. <!DOCTYPE html> Why Do We Need Web Sockets? Internet was conceived to be a collection of Hypertext Mark-up Language (HTML) pages linking one another to form a conceptual web of information. During the course of time, static resources increased in number and richer items, such as images and began to be a part of the web fabric. Server technologies advanced which allowed dynamic server pages – pages whose content was generated based on a query. Soon, the requirement to have more dynamic web pages lead to the availability of Dynamic Hypertext Mark-up Language (DHTML). All thanks to JavaScript. Over the following years, we saw cross frame communication in an attempt to avoid page reloads followed by HTTP Polling within frames. However, none of these solutions offered a truly standardized cross browser solution to real-time bi-directional communication between a server and a client. This gave rise to the need of Web Sockets Protocol. It gave rise to full-duplex communication bringing desktop-rich functionality to all web browsers. WebSockets – Functionalities Web Socket represents a major upgrade in the history of web communications. Before its existence, all communication between the web clients and the servers relied only on HTTP. Web Socket helps in dynamic flow of the connections that are persistent full duplex. Full duplex refers to the communication from both the ends with considerable fast speed. It is termed as a game changer because of its efficiency of overcoming all the drawbacks of existing protocols. Web Socket for Developers and Architects Importance of Web Socket for developers and architects − Web Socket is an independent TCP-based protocol, but it is designed to support any other protocol that would traditionally run
Communicating with Server
WebSockets – Communicating with Server ”; Previous Next The Web has been largely built around the request/response paradigm of HTTP. A client loads up a web page and then nothing happens until the user clicks onto the next page. Around 2005, AJAX started to make the web feel more dynamic. Still, all HTTP communication is steered by the client, which requires user interaction or periodic polling to load new data from the server. Technologies that enable the server to send the data to a client in the very moment when it knows that new data is available have been around for quite some time. They go by names such as “Push” or “Comet”. With long polling, the client opens an HTTP connection to the server, which keeps it open until sending response. Whenever the server actually has new data, it sends the response. Long polling and the other techniques work quite well. However, all of these share one problem, they carry the overhead of HTTP, which does not make them well suited for low latency applications. For example, a multiplayer shooter game in the browser or any other online game with a real-time component. Bringing Sockets to the Web The Web Socket specification defines an API establishing “socket” connections between a web browser and a server. In layman terms, there is a persistent connection between the client and the server and both parties can start sending data at any time. Web socket connection can be simply opened using a constructor − var connection = new WebSocket(”ws://html5rocks.websocket.org/echo”, [”soap”, ”xmpp”]); ws is the new URL schema for WebSocket connections. There is also wss, for secure WebSocket connection the same way https is used for secure HTTP connections. Attaching some event handlers immediately to the connection allows you to know when the connection is opened, received incoming messages, or there is an error. The second argument accepts optional subprotocols. It can be a string or an array of strings. Each string should represent a subprotocol name and server accepts only one of passed subprotocols in the array. Accepted subprotocol can be determined by accessing protocol property of WebSocket object. // When the connection is open, send some data to the server connection.onopen = function () { connection.send(”Ping”); // Send the message ”Ping” to the server }; // Log errors connection.onerror = function (error) { console.log(”WebSocket Error ” + error); }; // Log messages from the server connection.onmessage = function (e) { console.log(”Server: ” + e.data); }; Communicating with the Server As soon as we have a connection to the server (when the open event is fired) we can start sending data to the server using the send (your message) method on the connection object. It used to support only strings, but in the latest specification, it now can send binary messages too. To send binary data, Blob or ArrayBuffer object is used. // Sending String connection.send(”your message”); // Sending canvas ImageData as ArrayBuffer var img = canvas_context.getImageData(0, 0, 400, 320); var binary = new Uint8Array(img.data.length); for (var i = 0; i < img.data.length; i++) { binary[i] = img.data[i]; } connection.send(binary.buffer); // Sending file as Blob var file = document.querySelector(”input[type = “file”]”).files[0]; connection.send(file); Equally, the server might send us messages at any time. Whenever this happens the onmessage callback fires. The callback receives an event object and the actual message is accessible via the data property. WebSocket can also receive binary messages in the latest spec. Binary frames can be received in Blob or ArrayBuffer format. To specify the format of the received binary, set the binaryType property of WebSocket object to either ”blob” or ”arraybuffer”. The default format is ”blob”. // Setting binaryType to accept received binary as either ”blob” or ”arraybuffer” connection.binaryType = ”arraybuffer”; connection.onmessage = function(e) { console.log(e.data.byteLength); // ArrayBuffer object if binary }; Another newly added feature of WebSocket is extensions. Using extensions, it will be possible to send frames compressed, multiplexed, etc. // Determining accepted extensions console.log(connection.extensions); Cross-Origin Communication Being a modern protocol, cross-origin communication is baked right into WebSocket. WebSocket enables communication between parties on any domain. The server decides whether to make its service available to all clients or only those that reside on a set of well-defined domains. Proxy Servers Every new technology comes with a new set of problems. In the case of WebSocket it is the compatibility with proxy servers, which mediate HTTP connections in most company networks. The WebSocket protocol uses the HTTP upgrade system (which is normally used for HTTP/SSL) to “upgrade” an HTTP connection to a WebSocket connection. Some proxy servers do not like this and will drop the connection. Thus, even if a given client uses the WebSocket protocol, it may not be possible to establish a connection. This makes the next section even more important 🙂 The Server Side Using WebSocket creates a whole new usage pattern for server side applications. While traditional server stacks such as LAMP are designed around the HTTP request/response cycle they often do not deal well with a large number of open WebSocket connections. Keeping a large number of connections open at the same time requires an architecture that receives high concurrency at a low performance cost. Print Page Previous Next Advertisements ”;
WebSockets – JavaScript Application ”; Previous Next The following program code describes the working of a chat application using JavaScript and Web Socket protocol. <!DOCTYPE html> <html lang = “en”> <head> <meta charset = utf-8> <title>HTML5 Chat</title> <body> <section id = “wrapper”> <header> <h1>HTML5 Chat</h1> </header> <style> #chat { width: 97%; } .message { font-weight: bold; } .message:before { content: ” ”; color: #bbb; font-size: 14px; } #log { overflow: auto; max-height: 300px; list-style: none; padding: 0; } #log li { border-top: 1px solid #ccc; margin: 0; padding: 10px 0; } body { font: normal 16px/20px “Helvetica Neue”, Helvetica, sans-serif; background: rgb(237, 237, 236); margin: 0; margin-top: 40px; padding: 0; } section, header { display: block; } #wrapper { width: 600px; margin: 0 auto; background: #fff; border-radius: 10px; border-top: 1px solid #fff; padding-bottom: 16px; } h1 { padding-top: 10px; } h2 { font-size: 100%; font-style: italic; } header, article > * { margin: 20px; } #status { padding: 5px; color: #fff; background: #ccc; } #status.fail { background: #c00; } #status.success { background: #0c0; } #status.offline { background: #c00; } #status.online { background: #0c0; } #html5badge { margin-left: -30px; border: 0; } #html5badge img { border: 0; } </style> <article> <form onsubmit = “addMessage(); return false;”> <input type = “text” id = “chat” placeholder = “type and press enter to chat” /> </form> <p id = “status”>Not connected</p> <p>Users connected: <span id = “connected”>0 </span></p> <ul id = “log”></ul> </article> <script> connected = document.getElementById(“connected”); log = document.getElementById(“log”); chat = document.getElementById(“chat”); form = chat.form; state = document.getElementById(“status”); if (window.WebSocket === undefined) { state.innerHTML = “sockets not supported”; state.className = “fail”; }else { if (typeof String.prototype.startsWith != “function”) { String.prototype.startsWith = function (str) { return this.indexOf(str) == 0; }; } window.addEventListener(“load”, onLoad, false); } function onLoad() { var wsUri = “ws://127.0.0.1:7777”; websocket = new WebSocket(wsUri); websocket.onopen = function(evt) { onOpen(evt) }; websocket.onclose = function(evt) { onClose(evt) }; websocket.onmessage = function(evt) { onMessage(evt) }; websocket.onerror = function(evt) { onError(evt) }; } function onOpen(evt) { state.className = “success”; state.innerHTML = “Connected to server”; } function onClose(evt) { state.className = “fail”; state.innerHTML = “Not connected”; connected.innerHTML = “0”; } function onMessage(evt) { // There are two types of messages: // 1. a chat participant message itself // 2. a message with a number of connected chat participants var message = evt.data; if (message.startsWith(“log:”)) { message = message.slice(“log:”.length); log.innerHTML = ”<li class = “message”>” + message + “</li>” + log.innerHTML; }else if (message.startsWith(“connected:”)) { message = message.slice(“connected:”.length); connected.innerHTML = message; } } function onError(evt) { state.className = “fail”; state.innerHTML = “Communication error”; } function addMessage() { var message = chat.value; chat.value = “”; websocket.send(message); } </script> </section> </body> </head> </html> The key features and the output of the chat application are discussed below − To test, open the two windows with Web Socket support, type a message above and press return. This would enable the feature of chat application. If the connection is not established, the output is available as shown below. The output of a successful chat communication is shown below. Print Page Previous Next Advertisements ”;
WebSockets – Implementation
WebSockets – Implementation ”; Previous Next Web Sockets occupy a key role not only in the web but also in the mobile industry. The importance of Web Sockets is given below. Web Sockets as the name indicates, are related to the web. Web consists of a bunch of techniques for some browsers; it is a broad communication platform for vast number of devices, including desktop computers, laptops, tablets and smart phones. HTML5 app that utilizes Web Sockets will work on any HTML5 enabled web browser. Web socket is supported in the mainstream operating systems. All key players in the mobile industry provide Web Socket APIs in own native apps. Web sockets are said to be a full duplex communication. The approach of Web Sockets works well for certain categories of web application such as chat room, where the updates from client as well as server are shared simultaneously. Web Sockets, a part of the HTML5 specification, allow full duplex communication between web pages and a remote host. The protocol is designed to achieve the following benefits, which can be considered as the key points − Reduce unnecessary network traffic and latency using full duplex through a single connection (instead of two). Streaming through proxies and firewalls, with the support of upstream and downstream communication simultaneously. Print Page Previous Next Advertisements ”;
WebSockets – Duplex Communication ”; Previous Next Before diving to the need of Web sockets, it is necessary to have a look at the existing techniques, which are used for duplex communication between the server and the client. They are as follows − Polling Long Polling Streaming Postback and AJAX HTML5 Polling Polling can be defined as a method, which performs periodic requests regardless of the data that exists in the transmission. The periodic requests are sent in a synchronous way. The client makes a periodic request in a specified time interval to the Server. The response of the server includes available data or some warning message in it. Long Polling Long polling, as the name suggests, includes similar technique like polling. The client and the server keep the connection active until some data is fetched or timeout occurs. If the connection is lost due to some reasons, the client can start over and perform sequential request. Long polling is nothing but performance improvement over polling process, but constant requests may slow down the process. Streaming It is considered as the best option for real-time data transmission. The server keeps the connection open and active with the client until and unless the required data is being fetched. In this case, the connection is said to be open indefinitely. Streaming includes HTTP headers which increases the file size, increasing delay. This can be considered as a major drawback. AJAX AJAX is based on Javascript”s XmlHttpRequest Object. It is an abbreviated form of Asynchronous Javascript and XML. XmlHttpRequest Object allows execution of the Javascript without reloading the complete web page. AJAX sends and receives only a portion of the web page. The code snippet of AJAX call with XmlHttpRequest Object is as follows − var xhttp; if (window.XMLHttpRequest) { xhttp = new XMLHttpRequest(); } else { // code for IE6, IE5 xhttp = new ActiveXObject(“Microsoft.XMLHTTP”); } The major drawbacks of AJAX in comparison with Web Sockets are − They send HTTP headers, which makes total size larger. The communication is half-duplex. The web server consumes more resources. HTML5 HTML5 is a robust framework for developing and designing web applications. The main pillars include Mark-up, CSS3 and Javascript APIs together. The following diagram shows HTML5 components − The code snippet given below describes the declaration of HTML5 and its doctype. <!DOCTYPE html> Why Do We Need Web Sockets? Internet was conceived to be a collection of Hypertext Mark-up Language (HTML) pages linking one another to form a conceptual web of information. During the course of time, static resources increased in number and richer items, such as images and began to be a part of the web fabric. Server technologies advanced which allowed dynamic server pages – pages whose content was generated based on a query. Soon, the requirement to have more dynamic web pages lead to the availability of Dynamic Hypertext Mark-up Language (DHTML). All thanks to JavaScript. Over the following years, we saw cross frame communication in an attempt to avoid page reloads followed by HTTP Polling within frames. However, none of these solutions offered a truly standardized cross browser solution to real-time bi-directional communication between a server and a client. This gave rise to the need of Web Sockets Protocol. It gave rise to full-duplex communication bringing desktop-rich functionality to all web browsers. Print Page Previous Next Advertisements ”;
WebSockets – Opening Connections ”; Previous Next Once a connection has been established between the client and the server, the open event is fired from Web Socket instance. It is called as the initial handshake between client and server. The event, which is raised once the connection is established, is called the onopen. Creating Web Socket connections is really simple. All you have to do is call the WebSocket constructor and pass in the URL of your server. The following code is used to create a Web Socket connection − // Create a new WebSocket. var socket = new WebSocket(”ws://echo.websocket.org”); Once the connection has been established, the open event will be fired on your Web Socket instance. onopen refers to the initial handshake between client and the server which has lead to the first deal and the web application is ready to transmit the data. The following code snippet describes opening the connection of Web Socket protocol − socket.onopen = function(event) { console.log(“Connection established”); // Display user friendly messages for the successful establishment of connection var.label = document.getElementById(“status”); label.innerHTML = ”Connection established”; } It is a good practice to provide appropriate feedback to the users waiting for the Web Socket connection to be established. However, it is always noted that Web Socket connections are comparatively fast. The demo of the Web Socket connection established is documented in the given URL − https://www.websocket.org/echo.html A snapshot of the connection establishment and response to the user is shown below − Establishing an open state allows full duplex communication and transfer of messages until the connection is terminated. Example Building up the client-HTML5 file. <!DOCTYPE html> <html> <meta charset = “utf-8” /> <title>WebSocket Test</title> <script language = “javascript” type = “text/javascript”> var wsUri = “ws://echo.websocket.org/”; var output; function init() { output = document.getElementById(“output”); testWebSocket(); } function testWebSocket() { websocket = new WebSocket(wsUri); websocket.onopen = function(evt) { onOpen(evt) }; } function onOpen(evt) { writeToScreen(“CONNECTED”); } window.addEventListener(“load”, init, false); </script> <h2>WebSocket Test</h2> <div id = “output”></div> </html> The output will be as follows − The above HTML5 and JavaScript file shows the implementation of two events of Web Socket, namely − onLoad which helps in creation of JavaScript object and initialization of connection. onOpen establishes connection with the server and also sends the status. Print Page Previous Next Advertisements ”;