与许多实时设备保持连接

Question

我正在Linux上编写一个程序，通过UDP套接字同时控制大约1000个患者监视器。我已成功编写了一个库来解析和发送消息，以便从单个病人监护仪设备收集数据。设备上有各种调度约束，如下所示： -

• 每个设备必须在300毫秒的最大时间段内不断从计算机客户端获取活动请求（可能因不同设备而异），否则连接将丢失。
• 计算机客户端必须向设备发送轮询请求，以便在一段时间内获取数据。我正在从患者监视器轮询大约5秒的平均数据，因此，我需要每5 * 3 = 15秒发送一次轮询请求。如果我未能在15秒的时间内发送请求，我将丢失与设备的连接。

现在，我正在尝试扩展我当前的程序，以便它能够同时处理大约1000多个设备。现在，我的程序可以有效地处理和解析来自一个设备的响应。在处理多个设备的情况下，有必要同步来自不同设备的多个响应并将它们序列化并通过TCP套接字进行流式传输，以便远程计算机也可以分析数据。嗯，这不是问题，因为它是众所周知的多生产者和单一消费者问题。我主要担心的是，我应该使用什么方法来维护1000+设备的活动连接。

通过互联网阅读并浏览本网站上的类似问题后，我主要考虑两种选择： -

• 每台设备使用一个线程。为了控制1000+设备，我最终会制作1000多个线程，这对我来说看起来不太可行。
• 使用多路复用方法，选择需要注意的FD并一次处理一个。我不知道如何解决这个问题，如果考虑到上述两个常数，多路复用方法能够保持与所有设备的活动连接。

我需要一些关于如何处理这种情况的建议和建议，你需要通过UDP套接字来控制1000多个实时设备。每个设备每300毫秒需要一些活动信号（不同设备不同），并且它们在关联阶段提到的时间间隔的约3倍内需要轮询请求。例如，ICU中的患者监测器可能需要实时（1秒平均）数据，其中一般病房中的患者监测器可能需要10秒平均数据，因此，两个设备的轮询周期将是3 * 1（3秒）并且分别为3 * 10（30秒）。

由于 Shivam Kalra

Answer 1

在大多数情况下，这两种方法至少在功能上能够处理您描述的功能，但通过事物的声音，性能将是一个至关重要的问题。从您提供的数字看来，应用程序似乎可以是CPU封装。

多线程方法的优势在于可以使用机器上所有可用的CPU内核，但多线程程序因难以实现可靠性和健壮性而臭名昭着。

您还可以使用Apache旧的经过验证的分叉工作者模型 - 创建一个单独的进程来处理最多100个设备。然后，您可能需要编写代码来管理连接到进程的映射。

您还可以使用多个主机和一些机制在其中分发设备。这样做的好处是可以更容易地处理恢复情况。听起来你的应用程序很可能是关键任务，它可能需要架构，以便在任何一个硬件断开时，其他硬件将自动接管。