Origin of Websocket, socket.io with practical implementation cases and challenges
This blog is written to find out the origin of websocket when there was HTTP in place. What are the limitations of HTTP and how websocket can handle those limitations?
Also, we will figure out the use of the socket.io library. How socket.io is helpful.
What is Websocket?
WebSocket allows a user to send and receive messages to a server. So basically, this is a way of communication between Client and Server.
As per the conventional definition, WebSocket is a duplex protocol used mainly in the client-server communication channel. It’s bidirectional in nature which means communication happens to and fro between client-server.
The connection, developed using the WebSocket, lasts as long as any of the participating parties lays it off. Once one party breaks the connection, the second party won’t be able to communicate as the connection breaks automatically at its front.
The question here is why do we need websocket? –When we already have HTTP.
Let find out answer:
The idea of WebSocket was borne out of the limitations of HTTP-based technology. How HTTP works?
1) The client (browser) sends a request to the Server.
2) The client (browser) sends a request to the Server.
3) The server sends back the response.
4) A client receives the response.
5) The connection is closed.
Here HTTP request has served its purpose and closed the connection. But in situations – where server wants to send data to client- It is not possible – because connection is closed. There are certain applications like Trading app, news apps where server needs to send updated details to client whenever updates available.
So to handle such problems – HTTP Polling was introduced.
What is HTTP Polling ?
Here client will be sending HTTP request to the server repetitively at certain interval of time. So client here is checking with server repetitively for data/response – even if data is not available every time client making call - which is not very efficient. We are using unnecessary resources and the number of failed requests is also troublesome.
So to overcome this issue- HTTP long polling was introduced.
What is HTTP Long Polling?
So, what is long polling? HTTP Long Polling is a variation of standard polling that emulates a server pushing messages to a client (or browser) efficiently.
Long Polling basically involves making an HTTP request to a server and then holding the connection open to allow the server to respond at a later time (as determined by the server). Long polling is very expensive in terms of CPU, memory and bandwidth (As the blocking request hold the resources).
And finally we reached on the point of Web socket.
WebSocket is bidirectional, a full-duplex protocol that is used in the same scenario of clientserver communication, unlike HTTP it starts from ws:// or wss://. It is a stateful protocol, which means the connection between client and server will keep alive until it is terminated by either party (client or server). After closing the connection by either of the client and server, the connection is terminated from both ends. This is how after client-server handshaking, the client-server decide on a new connection to keep it alive, this new connection will be known as WebSocket. Once the communication link establishment and the connection are opened, message exchange will take place in bidirectional mode until connection persists between client-server. If anyone of them (client-server) dies or decide to close the connection is closed by both of the party.
Websocket are mostly used in real time web applications, gaming applications and chat applications.
Let’s see by code how websocket works.
Create two files – one for server and another for client.
Server file creation:
Create server.js file- in that file import ‘http’ module and make the server listening to port: 8000.
Client file creation: Create client.html file with below details In client file- it required to create websocket object with the help of WebSocket constructor. As in below case we have created ‘ws’ object. This provides an api to create and manage the websocket connection to server.
Here in above we can see we are providing url as ‘ws://localhost:8000’. It is starting with ws- which indicates this client is trying to connect with websocket server.
Now let’s convert our normal http server into websocket server with below steps. To create websocket server- we need to import ‘ws’ module. With the help of ‘ws’ module we will create websocket server and handover the http server to Websocket server. So http server is listening on port: 8000 - and Websocket is listening on http server.
The wss object helps us to listen to event emitted when certain things happens. Like the connection is established or handshake is complete or the connection is closed, etc.
The method 'on' expects two arguments: Event name and callback. Event name to recognize which Event to listen/emit and callback specifies what to do with it. Here, we are just logging the headers Event.
This is our HTTP header, let’s break it down to understand better.
First things you will notice is that we got the status code 101. You may have seen 200, 201, 404 status code but this looks different. 101 is actually the Switching Protocols status code. It says "Hey, I want to upgrade". Second line shows the Upgrade information. It specifies that it wants to upgrade to websocket protocol. This is actually what happens during the handshake. The browser uses the HTTP connection to establish the connection using HTTP/1.1 protocol and then it Upgrade it to websocket protocol.
Similarly, we can add one more event connection which is emitted when the handshake is complete. We will send a message to the Client upon successfully establishing a connection.
We are also listening for the event message coming from Client.
Here client listen the server message by onmessage method provided by Websocket API.
Onopen method will be called once connection is upgraded/established with server. And in this way data transfer is possible in both the direction. Here client don’t need to setup connection at every time with server.
When not to use WebSocket?
WebSocket can be used if we want any real-time updated or continuous streams of data that are being transmitted over the network. If we want to fetch old data, or want to get the data only once to process it with an application we should go with HTTP protocol.
In above scenario –we have proved the utilization of Websocket in place of HTTP. Then if websocket is there to serve our purpose then why to use socket.io?
In situation of creating big projects – You have to debug everything, you have to make your own subscription services. Your own protocol. Your own everything. And you have to make sure everything is quite sophisticated. And you'll make A LOT of mistakes along the way. You'll spend tons of time designing and debugging everything.
WebSocket doesn't work ideally in presence of Firewall and Antivirus.
WebSocket doesn't work ideally in presence of Proxy and Load Balancer either.
It means you have to deal with all these issues yourself. You worked for a few hours and added extra code to solve all these problems and your WebSocket connection is finally working properly. Choosing WebSocket for a big application isn’t an easy option if you're a one guy army or a small team trying to implement complex features. And that is why socket.io come into picture.
Socket.io
Socket.io uses WebSocket behind the scenes and takes care of all these problems so that we don't have to deal with them ourselves. It's just a wrapper over native WebSocket which provides a bunch of other cool features which makes our job easy as a developer.
Socket.IO is a JavaScript library for realtime web applications. It enables realtime, bi-directional communication between web clients and servers.
Socket.IO primarily uses the WebSocket protocol with polling as a fallback option, while providing the same interface. Although it can be used as simply a wrapper for WebSocket, it provides many more features, including broadcasting to multiple sockets, storing data associated with each client, and asynchronous I/O.