Web-Sockets part-1

What are web sockets and why do we use ??

Seamless communication is a must on the modern web. As internet speeds increase, we expect our data in real time. WebSocket, enables client and server in real time. With WebSockets, you can build multiplayer games, chat apps, and collaboration software that work on the open web.

WebSockets enable the server and the client to send messages to each other at any time. The connection is established only once at the beginning, and after that, there is an open channel for sending and receiving data. This is an entirely different pattern than a standard HTTP connection where to get data, the client has to request it, and then a connection is broken soon.

websockts.gif

In this above picture we can see user two clients are intracting with each other using in real-time. Here there is always a connection between client and server so whenever server get data for client it sent.

Key points:

  • WebSockets use HTTP protocol only to initiate communication channel

  • Every frame is sent by their own protocol via TCP connection in the transport layer of the OSI model.

  • A single server can have multiple WebSocket connections open simultaneously, and can even have multiple connections with the same client, which opens the door for scalability.

  • WebSockets can stream through many proxies and firewalls.

  • Websockets always try to make connection if client goes down and inform this.

What are the alternatives to web-sockets??

Nothing is perfect when it comes to the technology, every thing depends on it's use case When it comes to data delivery from the server to the client, we are limited to two general approaches: client pull or server push. As a simple example with any web application, the client is the web browser. When the website in your browser is asking the server for data, this is called client pull. The reverse, when the server is proactively pushing updates to your website, it is called server push.

Let’s dive into some of the alternatives:

  • Long polling (client pull)

  • Short polling (client pull)

  • Server-Sent Events (server push)

  • Real-time database from Firebase (with WebSockets under the hood)

To make this blog not boring we will have small introduction with all machenishms

Long polling:

Implementing a technique called HTTP long polling, where the client polls the server requesting new information. The server holds the request open until new data is available. Once available, the server responds and sends the new information. When the client receives the new information, it immediately sends another request, and the operation is repeated. long-polling.jpg

Here in this picture we can see client is requesting to the server and server is holding the request till the time a new server event occurs(a new data available).

Short polling:

In HTTP short polling,where the client polls the server requesting new information. Server responds with data or empty response and then client again make a new request. It creates much traffic (uses resources). So long polling is better than short polling.

Server-Sent Events (HTTP streaming)

Server sent events(SSE) is a pushing technology that enables pushing notification/message/events from the server to the client(s) via HTTP connection. HTTP provides a mechanism to push data from the server to clients via Server-Sent Events. SSE is a mechanism that allows the server to asynchronously push the data to the client once the client-server connection is established. The server can then decide to send data whenever a new portion of data is available. It can be considered as a one-way publish-subscribe model.

sse-diagram.png

In this above daigram we can see client is having initial connection after that whenever there is any event occurs server sent.