这个小型数据/命令广播应用程序的建议网络拓扑？

Question

我们正在组建一个系统,通过模数转换器卡读取~32个电压信号,对它们进行一些初步处理,并将结果(仍然分成32个通道)作为UDP数据包传递给网络,在那里它们由另一台计算机拾取并以各种方式(a)显示,(b)进一步处理,(c)搜索改变采集系统状态的标准,或(d)AC的某种组合.同时,GUI进程正在计算机上运行,​​后者通过UDP打包的命令消息在后面的进程(vis计算机)上运行,这些进程在数据生成计算机和vis计算机的多个进程中改变状态.

我是网络编程的新手,我很难选择网络拓扑.对于相对较小的应用程序,是否有任何关于网络拓扑的启发式(或书籍章节,论文),而不是灵活地传递数据,命令和命令确认的需要？

系统细节:

• 原始数据采集发生在一个Linux机器上.简单地处理数据,保存到磁盘和推送到网络使用大约25%的CPU容量和少量内存.少于0.5 Mb /秒的数据传输到网络.所有用于数据生成的代码都是用c ++编写的.

• 另一台linux机器运行多个可视化/处理/ GUI流程.GUI控制采集机和vis /处理/ GUI计算机本身的处理.这段代码主要是用c ++编写的,Python中有一些小实用程序.

• 我们将编写其他想要监听原始数据,处理过的数据和传递的所有命令的应用程序; 那些应用程序也希望发出命令 - 我们无法预测我们想要编写多少这样的模块,但我们期望有3或4个数据繁重的进程将所有32个输入流转换为单个输出; 以及3或4个一次性小应用程序,如"命令记录器".模块化要求意味着我们希望旧的数据生成器和命令发布者不知道有多少监听器在那里.我们还希望收件人能够确认命令.

• 这两台机器通过交换机连接,数据包(数据和命令,以及确认)都以UDP格式发送.

我们想到的五种可能性:

1. 数据流,命令和确认以端口号为目标.数据生成器将独立数据流作为UDP数据包发送到可视化计算机上由独立可视化工具进程绑定的不同端口号.每个进程还绑定一个侦听端口以接收传入命令,另一个端口用于传入确认传出命令.这个选项似乎很好,因为内核负责流量/过滤数据包; 但是很糟糕,因为在面对不可预测的附加模块时,很难看到进程如何相互对话; 它似乎也导致了绑定端口的爆炸.

2. 数据流通过端口号定向到各自的可视化器,每个进程绑定一个端口以侦听命令.但是所有命令发布者都将其命令发送到数据包转发器进程,该进程知道所有进程的命令输入端口,并将每个命令转发给所有进程.确认也会发送到此通用命令输入端口并转发到所有进程.我们将有关每个命令的预期目标和每个确认的信息打包到命令/ ack数据包中,因此进程本身必须筛选所有命令/确认以查找与它们相关的命令/确认.

3. 数据包转发器进程也是所有数据包的目标.所有数据包和所有命令包都被转发到40个不同的进程.这显然会给子网带来更多的流量; 它还可以清除绑定端口的爆炸.

4. 两个分组分发器可以在vis计算机上运行 - 一个向所有端口广播命令/ ack.另一个只将数据广播到可能需要数据的端口.

5. 我们的32个可视化流程可以捆绑到一个流程中,该流程可以为32个信号绘制数据,从而大大减少了选项3导致的额外流量.

如果你已经尝试过在少数机器上的多个进程之间传递数据,并且有一些关于哪些策略是健壮的智慧或经验法则,我将非常感谢你的建议!(欢迎在图片中澄清要求)

Answer 1

我没有足够的代表将这个问题移至programmers.stackexhange.com，所以我将在这里回答。

首先我会向你抛出相当多的技术，每一项你都需要看一下。

• Hadoop一个映射缩减框架。能够获取大量数据并跨分布式节点进行处理。

• Kafka一个性能极高的消息系统。我建议将其视为您的消息总线。

• ZooKeeper一个分布式系统，可让您“弄清楚”分布式系统的所有不同方面。这是一个分布式的协调系统

• 发布/订阅消息传递

• ∅mq 另一个套接字库，允许发布/订阅消息传递和其他 N 到 N 消息传递安排。

现在我已经向您介绍了一些技术，我将解释我会做什么。

创建一个允许您创建 N 个连接器的系统。这些连接器可以处理图中的数据/命令 N，其中 N 是特定信号。这意味着如果您有 32 个信号，您可以使用 32 个连接器来设置系统来“连接”。这些连接器可以处理双向通信。因此你的接收/命令问题。单个连接器会将其数据发布到特定于该信号的主题的某个东西，例如 Kafka。

使用发布/订阅系统。本质上发生的事情是连接器将其结果发布到指定主题。这个主题是你选择的。然后处理器（UI、业务逻辑等）监听特定主题。这些都是任意的，您可以根据需要进行设置。

 ============         =============      =====     ============       =============
 = Signal 1=  < --- > = Connector = < -- = K = --> = "signal 1" --->  = Processor =
 ============         =============      = a =     ============       =============
                                         = f =
 ============         =============      = k =     ============       =============
 = Signal 2=  < --- > = Connector = < -- = a = --> = "signal 2" --->  = Processor =
 ============         =============      =   =     ============   |   =============
                                         =   =                    |
 ============         =============      =   =     ============   |  
 = Signal 3=  < --- > = Connector = < -- =   = --> = "signal 3" --- 
 ============         =============      =====     ============       

在此示例中，第一个连接器将其结果“发布”到主题“信号1”，其中第一个处理器正在侦听该主题。发送到该主题的任何数据都会发送到第一个处理器。第二个处理器正在侦听“信号 2”和“信号 3”数据。这表示类似于同时检索不同信号的用户界面。

需要记住的一件事是，无论您选择什么主题，这种情况都可能发生。如果您认为重要，“处理者”可以收听所有主题。