超过 1024 个客户端使用 fd_set？

Question

我使用select() 来衡量服务器没有收到任何新消息的时间。代码很简单，看起来像这样：

int res = -1;
do {
    FD_ZERO(&readfds);
    FD_SET(sockfd, &readfds);
    res = select(maxfd+1, &readfds, NULL, NULL, &tv);
    gettimeofday(&current, NULL);
    if (get_time_diff(current, last) >= diff) {
        // do something
    }
} while (res <= 0);

当然，这不适用于超过 1024 个连接，因为fd_set 只有 1024 位。幸运的是，我不需要存储所有的 FD，我只需要知道何时发生新连接。所以我用服务器 FD 之后的下一个数字替换了maxfd+1（它总是相同的，在我的情况下等于 18）。

现在一切似乎都很好，所有客户端都从服务器收到了正确的消息。但是，我不确定它是否是一个有效的解决方案，而且它肯定不是一个非常干净的解决方案。这会导致我不知道的任何问题吗？

Answer 1

是的，select 受设计限制，与 fd 值超过 1023 一起使用是不安全的。

老实说，您可能找不到使用 select 的重负载生产服务器（如果有，那么您可能不应该使用它们）。

所以我将 maxfd+1 替换为服务器 FD 之后的下一个数字（始终相同，在我的情况下等于 18）。

我假设您的示例是一个最小示例，并且您不只是查看单个收听的 fd（否则，您可能会阻止 accept，这更有意义）。

这会提醒您打开了另一个文件描述符*...但是，我觉得这不是最好的方法，因为：

• 它只会对第一个文件描述符这样做......

  新客户端将根据第一个客户端的状态运行，它们自己的状态将被忽略，因为它们的fd 的状态从未经过测试。

• 它使您的代码既脆弱又僵硬。

• 其他文件描述符（非套接字）可能会占用特定的文件描述符，从而导致实现非常糟糕。

• 如果将文件描述符添加到集合中，您仍然需要测试它们的值。

更好的解决方案可能包括：

• 测试客户端的 fd 值并强制限制 (if (fd >= 1024) close(fd))。

• 使用 poll（老实说，这就是它存在的原因 - 引入它是为了解决 select 施加的限制）。

• 使用操作系统特定的 API（epoll 用于 Linux，kqueue 用于 BSD/macOS 等）。

• 使用抽象出操作系统特定 API 的库（例如，libev）。

祝你好运！

---

* Unix 风格的系统保证任何新的文件描述符都将被分配最低的fd 可用值。

这意味着您的第一个客户端将始终收到服务器 + 1（假设您没有打开或关闭任何其他文件描述符）。

但更新的文件描述符将被分配更高的值（除非更低的文件描述符可用）。因此，当您测试第一个客户端的状态时，永远不会轮询其他客户端。