Quickly Comprehend Persistent Connections And The Heartbeat Mechanism

Quickly Comprehend Persistent Connections and the Heartbeat Mechanism

Non-Persistent Connections

First let's have a look at what is Non-Persistent Connections: Non-persistent connections involve a single request-response cycle between a client and a server, and are suitable for applications with numerous short transactions.

What's the lifecycle of the Non-Persistent Connections: 1) Client and server establish a connection via a three-way handshake. 2) Client sends a request message, server responds. 3) Connection is closed.

Persistent Connections

Then what's the Persistent Connection? In persistent connections, the client and server maintain an open connection for multiple read/write operations.

Lifecycle

1) Client initiates connection, server accepts. 2) Connection remains open until requested to close or abnormal situations occur. 3) Can last for long periods of time (days, months, years).

What's the Pros and Cons

Non-Persistent Connections:

Pros: Resource efficiency: Non-persistent connections release resources when the connection is closed, reducing the overall load on the server. Suitable for short transactions: They are well-suited for applications with a large number of short, sporadic transactions, as they do not consume resources after the transaction is complete.

Cons: Increased overhead: Establishing and closing connections for each request-response cycle can consume additional resources, impacting performance. Slower for frequent transactions: Applications requiring rapid, continuous transactions may experience slower performance due to the overhead involved in establishing and closing connections.

Persistent Connections:

Pros: Reduced overhead: Since the connection remains open for multiple requests, it saves the time and resources required for establishing and closing connections. Improved performance: The reduced overhead can lead to faster response times for applications that involve frequent and continuous data exchange. Better error handling: Persistent connections allow for error prompts without needing to close the connection.

Cons: Resource consumption: Persistent connections consume server resources, as they remain open even when not actively transmitting data. Scalability issues: A large number of open connections can impact server performance and limit concurrency.

Use Cases

Non-Persistent Connection

Simple Data Requests: Non-persistent connections are commonly used in applications where simple data requests are required, such as a user making a single query to a search engine.

Low Traffic Applications: Applications with low traffic, such as personal blogs, may not require a persistent connection as the number of requests is low.

Limited Resources: Non-persistent connections are used in applications that have limited resources, such as mobile devices, to minimize the number of connections that need to be maintained.

File Downloads: Non-persistent connections are commonly used in file download applications where users download files intermittently.

One-Time Transactions: Non-persistent connections are useful for one-time transactions, such as completing an online purchase, where the user makes a single request and then disconnects.

Persistent Connection

Database Connectivity: Persistent connections are used to maintain database connections in applications such as web servers, where a large number of requests are received simultaneously.

Real-Time Communication: Persistent connections are useful in real-time communication applications such as video conferencing, voice over IP (VoIP), and instant messaging. In these applications, it is necessary to maintain a continuous connection between the client and server for the duration of the communication.

Streaming Services: Persistent connections are widely used in streaming services such as Netflix and Spotify, where a continuous stream of data is required.

WebSockets: Persistent connections are also used in WebSockets, a communication protocol that enables two-way communication between a client and a server over a single TCP connection.

Online Gaming: Persistent connections are used in online gaming applications to maintain real-time communication between players and the game server.

Internet of Things (IoT): Persistent connections are useful in IoT applications, where a large number of devices need to communicate with the server continuously.

Remote service calls (RPC) between servers.

Heartbeat Mechanism in the Persistent Connection

Introduction

A Heartbeat mechanism is used to maintain persistent connections by regularly sending data packets between the client and server.

Why is it needed?

To detect and maintain the connection's availability, prevent data loss, and ensure reliable communication between the client and server. In a persistent connection, the client and server keep the connection open for an extended period of time, even when there is no data being transmitted. During this period, network disruptions or equipment failure can cause the connection to be lost, resulting in data loss or other issues. For example, during unreliable networks can cause connection interruptions, and a Heartbeat mechanism helps detect offline clients or servers quickly.

How it works The Heartbeat Mechanism sends periodic messages from the client to the server to check whether the connection is still active. These messages are typically small and contain no useful data, but their purpose is to ensure that the connection remains open and active. If the server does not receive a heartbeat message within a specified time period, it assumes that the client is no longer active and closes the connection. This process helps prevent data loss and ensures that the connection remains available for use when it is needed.

Config the TCP KeepAlive The default state for KeepAlive is closed, and it can be turned on by the TCP settings. Additionally, you can tune the keepalive time,which represent the idle time before sending a KeepAlive ACK packet. Also the keep alive probes,the number of ACK packets sent before considering the other side disconnected. And also even the interval for the pings, the time between two ACK packets

Needs attention Many network devices, especially NAT routers, cannot maintain all connections on them due to hardware limitations such as memory and CPU processing power. Therefore, they may drop some inactive connections in the connection pool when necessary. Here is the "algorithm questions" come into the picture.

Do you know actually you can use LRU(Least Recently Used) to drop the longest inactive connection. How about write this code and email us your solution 😀

How to solve this problem? Let your TCP connections work properly no matter what the underneath routers or networks? One solution is by using TCP's KeepAlive mechanism and config properly, ACK packets can be generated at regular intervals to reduce the risk of being dropped, but this comes at the cost of additional network and CPU load.

How to Implement a Heartbeat Mechanism?

There are mainly two ways to implement a Heartbeat mechanism:

Option1: Directly use the build-in TCP KeepAlive mechanism. Option2: Implement a custom Heartbeat mechanism based on the business logic at the application layer.

The pros for option1: Using the TCP KeepAlive mechanism is more efficient in terms of traffic consumption than implementing a custom application-layer Heartbeat mechanism.

The disadvantages for the option1: Although the TCP protocol layer provides KeepAlive mechanisms, using it has several disadvantages:

1) It is turned off by default.

2) The TCP KeepAlive mechanism depends on the operating system's implementation, and the default heartbeat interval is two hours. Modifying the KeepAlive mechanism requires a system call or adjustment to the system configuration, which makes it less flexible and requires additional engineering effort. This modification also introduces more dependencies and potential failure points for the system, making it more challenging to debug.

3) The TCP KeepAlive mechanism is tightly bound to the TCP protocol. Therefore, if it needs to be replaced with the UDP protocol, the KeepAlive mechanism will be invalid.

The pros and cons for option2? Stay tuned for the next article: Persistent Connections for your Design Interview Part II