0

我正在 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 秒)。

谢谢希瓦姆卡拉

4

1 回答 1

3

在大多数情况下,这两种方法至少在功能上能够处理您描述的功能,但从事物的声音来看,性能将是一个关键问题。从您提供的数据看来,该应用程序可能是 CPU 密集型的。

多线程方法的优点是使用机器上所有可用的 CPU 内核,但多线程程序因难以可靠和健壮而臭名昭著。

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

您还可以使用多个主机和一些机制在它们之间分配设备。这将具有更容易处理恢复情况的优点。听起来您的应用程序很可能是关键任务,并且可能需要对其进行架构,以便如果任何一个硬件发生故障,那么其他硬件将自动接管。

于 2012-05-23T06:29:20.163 回答