通过UDP发送数据时，是否可以将数据流化为ZeroMQ消息？

Question

我们正在以30fps的延迟关键型应用程序进行工作，该应用程序处于开发阶段的多个阶段（例如，压缩，网络发送，图像处理，3D计算，纹理共享等）。

通常，我们可以实现以下多个阶段：

[Process 1][Process 2][Process 3]

---------------time------------->

但是，如果我们可以堆叠这些进程，则可能[Process 1]在处理数据时，它会不断将其结果传递给[Process 2] 。 这类似于iostream在c ++中的工作方式，即“流”。 使用线程可以减少延迟：

[Process 1]
    [Process 2]
        [Process 3]
<------time------->

我们假设[Process 2]是我们的UDP通信（即[Process 1]在计算机A上， [Process 3]在计算机B上）。

[Process 1]的输出大约为3 MB （即通常> 300个超大数据包，每个9 KB），因此我们可以假定当我们调用ZeroMQ时：

socket->send(message); // message size is 3 MB

然后，在库或OS中的某个位置，将数据拆分为按顺序发送的数据包。 该功能假定消息已经完全形成。

通过UDP发送大数据时，是否有某种方式（例如API）将消息的某些部分“构建中”或“按需构建”？ 并且这在接收端也是可能的（即，允许在消息的开头采取行动，因为消息的其余部分仍在传入）。 或者..是我们自己手动将数据分割成较小块的唯一方法吗？

Note:
网络连接是计算机A和计算机B之间的直线GigE连接。

Answer 1

TLDR; -简单的答案是不，ZeroMQ SLOC不会帮助您的项目获胜。 该项目可行，但是需要另一个设计视图。

陈述了最少的事实：
30fps ，
3MB/frame ，
-3级处理管道，
-私有主机-主机GigE互连，

没有更多细节，没有太多决定权。

当然，管道端到端处理的阈值大约为33.333 [ms] （而您计划通过networkIO直接损失大约30 [ms] ），其余的则留给设计人员。 哎哟!

延迟控制的设计不得跳过实时I/O设计阶段

ZeroMQ是强大的工具，但这并不意味着它可以节省设计不佳的情况。

如果您花了一些时间限制时序，则LAN networkIO延迟是您认为最严重的敌人。

参考： 每个人都应该知道的延迟数字

1） 设计处理阶段
2） BENCHMARK各阶段的实施模型
3）PARALLELISE无论Amdahl定律说，这是有意义的，如果可能的话

如果您的代码允许并行处理，则通过inproc:可以实现的ZeroMQ 零复制/（几乎） 零延迟/ 零阻塞，您的计划将更好地利用“渐进式”流水线处理inproc:在多个处理阶段中，您的代码可能支持“渐进式”流水线。

请记住，这不是单线的，也不希望SLOC控制您的“渐进式”流水线制造。

[ns]重要 ，请仔细阅读数据处理微基准测试中的数字。
他们确实决定您的成功。
在这里，您可能会看到仅更改颜色表示就浪费了多少时间，代码在对象检测，3D场景处理和纹理后处理中将需要这些时间。 因此，将您的设计标准设置为较高的标准水平。

检查此实时管道中丢失的毫秒numbers以左下角显示 。

如果你的代码的处理要求不放心地融入你的33,000,000 [ns]时间预算与{ quad | hexa | octa }-core { quad | hexa | octa }-core { quad | hexa | octa }-core CPU资源，如果数值处理可以受益于many-core GPU资源，有可能是这种情况，那Amdahl定律可能 证明某些异步多GPU核的处理方法，与他们额外的+21,000 ~ 23,000 [ns]失去了在初始/终端的数据传输+350 ~ 700 [ns]通过引入GPU.gloMEM -> GPU.SM.REG延迟掩蔽（其具有愉快地在图像处理的情况下，足够的准平行螺纹深度，甚至对于预期的琐碎GPU内核的低计算密度）
Ref.:
GPU / CPU延迟应根据以下条件验证初始设计：

Answer 2

不，您不能现实地做到这一点。 API并未提供此功能，ZeroMQ承诺接收方将获得完整的消息（包括多部分消息）或根本没有消息，这意味着在完全传输之前，它不会向接收方显示消息。 将数据自己拆分为可单独操作的块，这些块作为单独的ZeroMQ消息发送，这是正确的选择。