Client Polling vs Server Push vs Websocket vs Long Polling

Client Pull vs Server Push
Building a real-time web application is a bit challenging one, where we need to
consider how we are going to send our data from the server to the client.
Client pull — client asking server for updates at certain regular intervals
Server push — server is proactively pushing updates to the client (reverse of
pull)
Long Polling - client makes a request to the server, but this is kept open until a
"useful" response is returned. Problem with Long polling are empty responses,
wasting bandwidth and server resources.

The difference between push & pull technology is that when a client
initiates a request from the server, it’s called a pull, and when a
server sends the information to the client within any requests, it’s
called a push.

What is server push ?
Push Technology can be referred to as pushing the information from the server
without the client’s request. It’s the opposite of the traditional client/server model,
where clients need to request a server to push the information.
It’s used to share the pre-planned information to the client like news, weather, updates
and other information that clients have not requested, but servers push the information
based on the client’s activities. Push Technology is mainly used in business to share
time-sensitive information, commodity pricing, new program promotion, or
communicate with clients and employees.
Ex of Push – Email, Push Notification on mobile app etc.

Client Polling Mechanism
The basic idea is that the client repeatedly polls (or requests) a server for data.
The client makes a request and waits for the server to respond with data. If no
data is available, an empty response is returned. Pull Technology can be referred
to as communication between client & server. It’s a traditional way of
communication between client & server. Pull Technology is mainly used to drive the
content to many applications and devices; whenever a user browses, it implies a Pull
technology where a client pulls information from the server.

Client Polling Mechanism
1.The client opens a connection and requests data from the server using
regular HTTP.
2.The requested web page sends requests to the server at regular intervals
(e.g., 0.5 seconds).
3.The server calculates the response and sends it back, just like regular HTTP
traffic.
4.The client repeats the above three steps periodically to get updates from the
server.

Client Polling Mechanism
The problem with Polling is that the client has to keep asking the server for any
new data. As a result, a lot of responses are empty, creating HTTP overhead.

Pull Mechanism Push Mechanism
When a client requests the server for the information
called pull technology.
When a server updates the information to the client
without waiting for a request called push technology.
A user using a web browser and requesting for a
web page.
An email is immediately sent from the server to the
client.
Pull Technology is used when advertisers want to
reach global audiences or build a customer base.
Push Technology is used by online advertisements,
chat, email systems, security applications and RSS
feeds.

Long Polling Mechanism
•If the server does not have any data available for the client, instead of sending
an empty response, the server holds the request and waits until some data
becomes available.
•Once the data becomes available, a full response is sent to the client. The
client then immediately re-request information from the server so that the
server will almost always have an available waiting request that it can use to
deliver data in response to an event.

Long Polling Mechanism
1.The client makes an initial request using regular HTTP and then waits for a
response.
2.The server delays its response until an update is available or a timeout has
occurred.
3.When an update is available, the server sends a full response to the client.
4.The client typically sends a new long-poll request, either immediately upon
receiving a response or after a pause to allow an acceptable latency period.
5.Each Long-Poll request has a timeout. The client has to reconnect periodically
after the connection is closed due to timeouts.

Long Polling Mechanism drawback
1.Message ordering and delivery guarantees.
1.Message ordering cannot be guaranteed if the same client opens multiple
connections to the server.
2.If the client was not able to receive the message then there will be possible
message loss.
2.Performance and scaling.
3.Device support and fall backs.

What is Websocket ?
WebSocket is a computer communication protocol which provides full-
duplex communication channels over a single TCP connection.
•It is different from HTTP but compatible with HTTP.
•Located at layer 7 in the OSI model and depends on TCP at layer 4.
•Works over port 80 and 443 ( in case of TLS encrypted) and supports HTTP
proxies and intermediaries.
•To achieve compatibility, the WebSocket handshake uses Upgrade header to
update the protocol to the WebSocket protocol.

Websocket

WebSocket workflow
1.A client initiates a WebSocket handshake process by sending a request which
also contains Upgrade header to switch to WebSocket protocol along with
other information.
2.The server receives WebSocket handshake request and process it.
1.If the server can establish the connection and agrees with client terms then
sends a response to the client, acknowledging the WebSocket handshake
request with other information.
2.If the server can not establish the connection then it sends response
acknowledging it cannot establish WebSocket connection.
3.Once the client receives a successful WebSocket connection handshake
request, WebSocket connection will be opened. Now, client and servers can
start sending data in both directions allowing real-time communication.
4.The connection will be closed once the server or the client decides to close
the connection.

WebSocket Pros and Cons
Pros
•WebSockets keeps a unique connection open while eliminating latency problems
that arise with Long Polling.
•WebSockets generally do not use XMLHttpRequest, and as such, headers are not
sent every-time we need to get more information from the server. This, in turn,
reduces the expensive data loads being sent to the server.
Cons
•WebSockets don’t automatically recover when connections are terminated — this is
something you need to implement yourself, and is part of the reason why there are
many client-side libraries in existence.
•Browsers older than 2011 aren’t able to support WebSocket connections — but this
is increasingly less relevant.

WebSocket vs Long polling
Long polling is much more resource intensive on servers whereas WebSockets
have an extremely lightweight footprint on servers. Long polling also requires
many hops between servers and devices. And these gateways often have
different ideas of how long a typical connection is allowed to stay open. If it
stays open too long something may kill it, maybe even when it was doing
something important.
Why you should build with WebSockets:
•Full-duplex asynchronous messaging. In other words, both the client and the
server can stream messages to each other independently.
•WebSockets pass through most firewalls without any reconfiguration.
•Good security model (origin-based security model).

Server Push
Server-Sent Events are a one-way communication channel where events flow
from server to client only. Server-Sent Events allows browser clients to
receive a stream of events from a server over an HTTP connection without
polling.
A client subscribes to a “stream” from a server and the server will send
messages (“event-stream”) to the client until the server or the client closes the
stream. It is up to the server to decide when and what to send the client, for
instance as soon as data changes.

Server
Push

Server Push workflow
1.Browser client creates a connection using an EventSource API with a server
endpoint which is expected to return a stream of events over time. This
essentially makes an HTTP request at given URL.
2.The server receives a regular HTTP request from the client and opens the
connection and keeps it open. The server can now send the event data as long
as it wants or it can close the connection if there are no data.
3.The client receives each event from the server and process it. If it receives a
close signal from the server it can close the connection. The client can also
initiate the connection close request.

WebSocket vs Server Push
WebSockets are undoubtedly more complex and demanding than SSEs, and
require a bit of developer input up front. For this investment, you gain a full-
duplex TCP connection that is useful for a wider range of application scenarios.
For example WebSockets tend to be preferable for use cases such as multi-
player games or location-based apps. Where Serve Push can technically be
used to achieve these, this might cause the domain to get multiplexed.

WebSocket vs Server Push
WebSockets provide bidirectional client-server communication between clients and
servers. This kind of functionality is vastly applied and appreciated in technologies
technologies like real-time polling applications, chat applications, media players and
players and the like.
Server Push do not provide bidirectional communication. However, there are so
many applications where there’s no need to send data from the client. Cases like this
like this are updating statuses, push notifications, newsletters and news feeds. In
In scenarios like this, SSEs are most appreciated.

THANK YOU
Like the Video and Subscribe the Channel