Socket编程：服务器最大客户端连接数及闲置连接识别问题

Great questions—these are super common hurdles when building scalable socket servers, so let’s break them down clearly:

1. Is the maximum number of client connections really 1024? #

The short answer is no, not by default, and definitely not as a hard limit. Here’s why:

• The 1024 number you’re thinking of is the default per-process file descriptor limit on most Unix-like systems (you can check this with ulimit -n). Since each accepted client connection uses a file descriptor, this does cap connections at 1024 out of the box—but this limit is adjustable.
  • Temporary fix: Run ulimit -n 65535 in your shell session to raise the limit for the current process.
  • Permanent fix: Edit /etc/security/limits.conf to set soft and hard limits (like * soft nofile 65535 and * hard nofile 65535), then reboot or re-login for changes to take effect.
• Beyond file descriptors, you also need to consider the backlog parameter in the listen() call. This controls the number of pending connections waiting to be accepted by your server. Modern kernels interpret this as a combined limit for half-open (SYN_RECV) and fully open (ESTABLISHED) queues, so you can increase this too (e.g., listen(sockfd, 1024) or higher, depending on your kernel’s max allowed value).
• Keep in mind that actual maximum connections will also depend on system resources: each connection uses memory for socket buffers, process state, etc. But with proper tuning, you can easily handle tens of thousands of connections on a modern server.

2. How to identify idle clients that just keep connections open without activity? #

There are three reliable approaches to handle this, depending on your needs:

• TCP Keep-Alive (kernel-level)：Enable the SO_KEEPALIVE socket option to let the kernel automatically probe idle connections. If the client doesn’t respond to a series of probes, the kernel will mark the connection as dead and notify your program. To set this in code (e.g., C):

  int keepalive_enabled = 1;
  setsockopt(client_fd, SOL_SOCKET, SO_KEEPALIVE, &keepalive_enabled, sizeof(keepalive_enabled));
  

  You can tweak kernel parameters like net.ipv4.tcp_keepalive_time (how long to wait before sending first probe), net.ipv4.tcp_keepalive_intvl (probe interval), and net.ipv4.tcp_keepalive_probes (number of probes before marking dead) to adjust behavior.
• Application-Level Heartbeats：This is more flexible than TCP keep-alive because you control the exact logic. Define a simple heartbeat protocol (e.g., client sends a PING message every 30 seconds, server responds with PONG). If the server doesn’t receive a heartbeat within a set window (say, 60 seconds), it can safely close the connection. This works well if you need to distinguish between network blips and truly idle clients.
• Read/Write Timeouts：Set timeouts on your socket’s read/write operations. You can do this with select()/poll()/epoll() by specifying a timeout value, or by setting the SO_RCVTIMEO and SO_SNDTIMEO options with setsockopt(). If a read operation times out (no data received in X seconds), you can assume the client is idle and close the connection.

内容的提问来源于stack exchange，提问作者Swapnil