•  Web
•  
  .net

What is Polling

Whenever a message is to be exchanged between the devices in the network they follow certain rules for message exchange. The server and various client devices form a clusters network. The server being the central controlling entity, all clients send messages randomly. To avoid the accumulation of messages from the clients the server polls them, based on their respective polling sequence the devices forward their data packets to the server, this is how the basic polling method work, the whole polling protocol is based on the HTTP request/response model. These request/response model includes all handshake signals.

Introduction to HTTP Request/Response model

Most of the internet works over the Http Request-Response model where the client sends the request to the server, based on which the server sends back a response. In a simple language when we click on a link and request the server to give us a page the server responds with the content of the page. The important thing to note here is that the client has to initiate a request before the server sends back a response. The server is constantly waiting for the request to be initiated, it cannot independently push data to the client. This model works efficiently when the server has the pool of data already available with it.

Why Polling is outdated

The other way around was using a polling method. Initially, the client will check with the server for new data at predefined intervals, here still server cannot send a response without the client's request, however, the request by the client is placed periodically and response is provided periodically by the server. Depending on how short is the time gap between each automatic request, that the client sends, short polling can feel like real-time.

An alternative method for achieving the experience of real-time is long polling. The client makes a request, the server holds onto the request till new data is available. Only when the new data is available the server sends data to the client and the moment the client receives the new data it immediately and automatically pulls a new request to the server for new data again. So even this seems like a viable option for a chat application. The problem with the polling system is, the server responds only to the request made by the clients which becomes a half-duplex, unidirectional type of communication.

Even though long polling seems real-time it isn't, as polling makes the server intensively loaded and the server undergoes constant data processing, there is a huge bandwidth consumption involved, in this technique, the server elects to hold open a clients connection for as long as the data becomes available or the timeout thresholds has been reached. There is also a huge possibility of generating duplicate data at the server as the client keeps sending multiple HTTP requests in-flight simultaneously. Moreover, it is also possible to receive an acknowledgment message intended for a client to be accepted by another client instead of its expected response.

If we overlook the limitations of long polling, there are the following challenges:

IP addresses constantly change with the change in the available networks like rapid switching of devices between WiFi and Cellular network, long polling can not automatically re-establish connections. In polling when messages get in a queue the reliability of message delivery reduces. There is no built-in guarantee that data duplication will not occur more than once. When a system spreads connections across multiple servers the system ends up having session stickiness. The use of Sticky load balancer creates severe issues concerning security:

• It results in an uneven distribution of connections between servers. The devices or clients so connected may end up using the same server, leaving other servers empty.

• Since the host selection is deterministic a malicious user can trick load balancer, target and cripple a targetted server within a network being vulnerable to DoS (Denial of Service) or DDoS (Distributed DoS) attacks.

An extra burden of responsibilities in HTTP long polling is involved like updating, maintaining and scaling the back-end infrastructure, this requires its own discrete management system in building a real-time application which is a tedious task. Instead of faking the handshake connections to be real-time communication one should opt for the actual real-time communication.
 

Actual real-time communication with Yalgaar

Yalgaar provides messaging capabilities wherein the server doesn't have to wait for the device or client to send any new data the moment the server receives any new data, the server sends it automatically to the client. This mode of response is called a bidirectional, full-duplex communication over a single TCP connection. This connection is permanent until either the device or the server chooses to close it. The server doesn't have to wait for the client or a device to request data transfer. Lets us assume the are several devices connected to the server together, the moment the device or a client has data to send, it keeps the data on the channel for the server. The server proactively dispatches the message to all the clients connected, without those clients having to poll the server for new data and when one of the devices or client sends a message to a group, the server can push the message to all the connected clients instantly without each client having to ask the server to send. This real-time information exchange is what makes communication with devices and the client's specific application more efficient and alive. Yalgaar has its communication management system, which is responsible for updating, maintaining, and scaling the backend infrastructure. Yalgaar has low latency and low overhead. The fact that most web apps are moving to HTTPS anyway, we think that now is a good time to re-evaluate our options when it comes to building real-time apps and services.