Skip to main content

Client-Server Communication Model (Part-1)

The foundation of the internet lies in the communication between computers. Computers, acting as servers, own and can provide resources to other computers, serving as clients. The roles of computers shift over time – one moment, a computer may own resources, while at another time, it may require resources from others. Communication is essential for data exchange between them. The predominant protocol facilitating Client-Server communication is the HyperText Transfer Protocol (HTTP).

HTTP is a protocol for fetching web pages, documents, images, media files, binaries, etc. Pretty much the whole of the internet runs on HTTP. We have discussed HTTP in detail here. A typical HTTP request flow is as follows:

  1. A client opens a connection and requests a resource from a server.
  2. The server calculates the response
  3. The server sends the response to the client on the same opened connection
Some of the most popular Client Server Communication models are:
  1. Polling / Short Polling / AJAX Polling
  2. Long Polling
  3. Webhook
  4. Server-Sent Events
  5. WebSocket

1. Polling / Short Polling / AJAX Polling

The client requests data from the server at regular intervals and if it is available, the server returns a response, otherwise, it returns an empty response. It involves making repetitive HTTP requests with a shorter time gap between each call. The flow is as follows:

  1. The client makes a request to the server.
  2. The server responds either with the data itself or an empty response
  3. After receiving the response from the server, the client will wait for the specified interval and repeat the previous actions.

Advantages:

  • Short polling is easier to implement on both the client and server sides. If simplicity is a priority and real-time updates are not critical, short polling may be preferred for its straightforward implementation. 
  • In environments where legacy browsers lack support for modern techniques like WebSockets, short polling might be a fallback option. It can work in most web browsers without requiring additional technologies or server configurations.
  • Short polling can be easier to debug and test, as it follows a more traditional request-response model. This simplicity in debugging might be beneficial during the development phase.

Limitations:

  • Short polling may result in unnecessary server processing and bandwidth usage, especially when the client often receives responses indicating no new data. This inefficiency can be problematic in terms of resource utilization.
  • Short polling may face challenges in large-scale systems with a high number of clients. The constant polling from a large number of clients can strain the server and hinder overall system performance.
  • Frequent polling, even when there are no updates, can lead to increased battery consumption on mobile devices.

2. Long Polling

The main issue with Polling is connection has to be created repeatedly whenever the client needs to make a request, adding a lot of load on the server. Considering the server is required to serve several other clients, this repeated polling could become a bottleneck. Long Polling tries to minimize this.

With long polling, the client also repeatedly requests data from the server. But compared to short polling, the server holds the connection for a time until it has something to share or a timeout occurs. The flow is as follows:
  1. The client makes a request to the server.
  2. If the data is available on the server, it responds with the data itself, otherwise, the server holds the connection until the data is available or a timeout occurs.
  3. Once the client receives a response from the server, it makes a new request without waiting.

Advantages:

  • Long polling involves making periodic requests to the server, but these requests are less frequent compared to short polling. This can result in reduced server load, resource consumption, and decreased network traffic.
  • Long polling can be more scalable than short polling, especially when there are many clients. The longer duration of each request reduces the frequency of incoming requests, easing the server load.
  • Long polling requests often have a longer duration, making them less likely to be blocked by firewalls that may terminate short-lived connections. This improves the likelihood of successful communication in certain network environments.
  • Long polling requests have a defined duration, making it easier to predict when the next request will be made. This predictability can be advantageous in certain applications.

Limitations:

  • Although long polling reduces the frequency of requests, the open connections may lead to increased resource usage on the server, particularly in scenarios with a high number of long-lived connections.
  • Long polling maintains an open connection for an extended period, which can result in increased connection overhead, especially when dealing with a large number of clients. This may impact server scalability.
  • While Long polling allows the server to push data to the client, the client still needs to initiate a new connection for each update. It may not be as efficient as true bidirectional communication.

3. Webhook

A webhook is a mechanism in client-server communication that enables real-time data delivery from a server to a client by triggering HTTP requests. Instead of the client repeatedly polling or requesting data from the server, the server sends data to a predefined URL (webhook) associated with the client whenever there is new information or an event of interest. In the context of Webhooks, the term "client" typically refers to another system, like a web server. The typical Webhook flow is as follows:
  1. Registration: The client registers or subscribes to a particular event or set of events on the server. This involves providing a callback URL (webhook URL) where the server should send notifications.
  2. Event Occurrence: When the specified event occurs on the server (e.g., a new message in a chat application, a new order in e-commerce, a new comment on a social media post, etc), the server initiates an HTTP request to the callback URL. 
  3. Data Payload: The server includes relevant data in the HTTP request payload, providing details about the event or changes that triggered the webhook. It sends the payload in the language understood by both parties, usually JSON or XML.
  4. Client Handling: The client's server receives the incoming HTTP request, processes the data payload, and takes appropriate actions based on the event. This could involve notifying users, updating data, or triggering further processes. 

Advantages:

  • Webhooks eliminate the need for frequent polling by delivering updates only when there is new information. This efficient use of resources reduces unnecessary network traffic and server load.
  • Webhooks follow an event-driven architecture, enabling clients to respond to specific events without continuously querying the server. This makes the communication model more responsive and tailored to relevant events. It ensures real-time or near-real-time updates to clients, allowing them to receive information as soon as events occur on the server. 
  • Webhooks facilitate bidirectional communication by allowing servers to initiate communication and push data to clients. This is particularly valuable for real-time applications and instant updates.
  • Webhooks can be implemented in a scalable manner, allowing a large number of clients to receive updates without straining server resources. This makes them suitable for applications with varying workloads.

Limitations:

  • Ensuring the security of webhooks is crucial. If not properly implemented, webhooks may be susceptible to unauthorized access or malicious use. Proper authentication mechanisms are essential to mitigate security risks. Let's understand the risk with a hypothetical scenario:
    • A user subscribes to the chat application's webhook by providing a callback URL (webhook endpoint) where notifications will be sent. The user's server is responsible for handling incoming webhook payloads.
    • The chat application's server does not implement strong authentication or proper protection mechanisms for its webhook endpoint. The endpoint is publicly accessible, and there is no verification of the source of incoming requests.
    • An attacker identifies the unprotected webhook endpoint and crafts a fake HTTP request, mimicking the format expected by the chat application. The attacker sends this fake request to the user's webhook endpoint, pretending to be the chat application server.
    • The attacker successfully injects malicious or unwanted data into the user's chat application through the unprotected webhook. 
  • Webhook payloads are subject to size limitations imposed by the server or network infrastructure. Large payloads may be problematic, leading to issues with data delivery.
  • Changes in the payload structure or behavior of webhook notifications may pose challenges, especially if clients and servers are not aligned with the same version. Proper versioning practices are needed to address compatibility issues.

Webhook Real Life Applications:

  • Webhooks are used by Payment Systems to notify merchants or users about the status of transactions, allowing them to update order statuses or take necessary actions.
  • E-commerce platforms utilize webhooks to notify sellers or administrators of new orders, changes in inventory, or other critical events, enabling timely action.
  • Monitoring systems use webhooks to send instant alerts to administrators or relevant teams when there are issues or changes in system health, ensuring a quick response.
  • IoT devices utilize webhooks to send updates about their status, sensor readings, or any significant events to central servers or applications.
Next, we will discuss how the client and server communicate through a continuous stream of data using Server-Sent Events and WebSockets in the next part.


Comments

Post a Comment

Popular posts from this blog

CAP Theorem - Debunking Myths

The CAP theorem is a widely recognized idea in the field of distributed systems. It represents three key concepts: Consistency, Availability, and Partition Tolerance. While most of us are familiar with its definition, the devil lies in the details. In this discussion, we'll clarify common myths and misunderstandings. We'll start by explaining the CAP theorem in detail, and then explore various scenarios that may challenge the common interpretation of it. CAP theorem also known as Brewer's theorem states that any distributed data store can provide only two of the following three guarantees: Consistency:  For every read request, the system should provide the most recent write or an error. Note that this consistency is different from the consistency of the  ACID theorem Availability:   For every request, the system should provide a response, even if it’s not the latest data.  In other words, all non-failing (healthy) nodes in the distributed system return a valid ...
Post a Comment
Read more

Understanding Merkle Tree

A Merkle Tree is a cryptographic tree structure used in computer science and distributed systems to efficiently verify the integrity of large sets of data (accuracy and consistency of data over its lifecycle).  Merkle Tree, also known as Hash Tree is a tree of hash values.  It has a tree structure in which each leaf node is a hash of a small portion of the data, and each non-leaf node is a hash of its children. It is used in applications such as  NoSQL databases, Git, Cryptocurrencies,  File Systems, etc. Some key characteristics of Merkle Tree are: Binary Tree Structure:  The Merkle Tree is a binary tree, where each leaf node represents a hash of data. Leaf Nodes: The data set is divided into fixed-size blocks or "leaves". Each leaf node contains the hash of a specific data block or piece of information. Non-Leaf Nodes: Non-leaf nodes in the tree represent the hash of the concatenation of their child node's hashes.  If the number of leaves is odd...
Post a Comment
Read more

Event Driven Architecture - SAGA Pattern (Part-1 : Choreography Model)

The Saga pattern is a distributed transactional pattern used in microservices architecture to maintain data consistency across multiple services. It helps manage long-running transactions involving multiple services by breaking them down into smaller, more manageable work units. There is a famous Database per Service  pattern in the Microservice world. Under this paradigm, each service maintains its own dedicated database. Some business transactions, however, span multiple services so we need a mechanism to implement transactions that span through services. Take, for instance, the scenario of placing an online order, which involves actions like inventory verification and item reservation till payment completion. Since services such as Orders, Inventory, and Payment operate on separate databases, the application cannot simply use a local ACID transaction. 2 Phase Commit Protocol  is one of the options being used for ensuring transactions across services. However, it has se...
Post a Comment
Read more