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

时间：2011-08-20 00:59:08

标签： c++ linux sockets network-programming signal-processing

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

我是网络编程的新手，正在努力选择网络拓扑。对于相对较小的应用程序，是否有任何关于网络拓扑的启发式（或书籍章节，论文），而不是灵活地传递数据，命令和命令确认的需要？

系统详情：

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

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

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

  • 这两台机器通过交换机连接，数据包（数据和命令，以及确认）都以UDP格式发送。

我们想到的五种可能性：

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

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

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

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

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

    6. 如果您已尝试在少数计算机上的多个流程之间传递数据，并且对于哪些策略是强大的，我们有一些智慧或经验法则，我非常感谢您的建议！ （欢迎在图片中澄清要求）

1 个答案:

答案 0 :(得分：2)

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

首先，我将为您提供相当多的技术，每个技术都需要您查看。

  • Hadoop map-reduce框架。能够获取大量数据并在分布式节点上处理它。

  • Kafka性能极高的消息传递系统。我建议将此视为您的消息总线。

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

  • Pub/Sub Messaging

  • ∅mq另一个允许发布/发送消息传递和其他N-to-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”数据。这表示用户界面同时检索不同的信号。

要记住的一件事是，这可能发生在您选择的任何主题上。如果您认为重要，“处理器”可以收听所有主题。

相关问题
最新问题