是否可以将数据流式传输到ZeroMQ消息中，因为它是通过UDP发送的？

Question

我们正在 30fps 处理延迟关键型应用程序，管道中有多个阶段（例如压缩，网络发送，图像处理，3D计算，纹理共享）等等。）

通常我们可以像这样实现这些多个阶段：

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

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

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

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

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

[Process 1]的输出约为 3 MB （即通常>每次9 KB的300个巨型数据包），因此我们可以假设当我们调用时ZeroMQ ＆＃39; S：

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

然后在库或OS中的某处，数据被分成按顺序发送的数据包。此功能假定消息已完全形成。

是否有一种方法（例如API）可以使邮件的某些部分正在构建中。或者按需建造＆＃39;在UDP上发送大数据时？并且这也可能在接收方（即允许在消息的开头起作用，因为消息的其余部分仍在传入）。或..是我们自己手动将数据拆分成较小块的唯一方法吗？

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

Answer 1

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

陈述了一组最低限度的事实：
- 30fps ，
- 3MB/frame ， - 3级处理流水线， - 私有主机 - 主机GigE互连，

没有进一步的细节，没有太多决定。

当然，管道端到端处理有一个大约 33.333 [ms] 的阈值（而您打算丢失一些 30 [ms] 直接 networkIO ），其余的你留给设计师的手。哎哟！

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

ZeroMQ 是一个强大的力量，但这并不意味着，它可以挽救糟糕的设计。

如果您在时间限制上花费一些时间，则LAN networkIO 延迟是您视图中最大的敌人。

参考： Latency numbers everyone should know

1） DESIGN 处理阶段
2） BENCHMARK 每个阶段的实施模式
3） PARALLELISE Amdahl's Law says哪里有意义且尽可能

如果您的代码允许进行并行处理，那么您的计划将更好地利用＆＃34;渐进式＆＃34; -pipeline处理，并使用 ZeroMQ inproc: 传输类和 SLOC 传输类中可实现<零 -copy /（几乎）零 -latency / 零 -blocking您可以在多个处理阶段中支持＆＃34; progressive＆＃34; -pipelining。

请记住，这不是一个单行，并且不要指望 [ns] 来控制你的渐进＆＃34; - 流水线制作。

numbers问题，请仔细阅读数据处理微观基准中的数据。
他们确定您的成功。 在这里你可以看到多少时间＆＃34;丢失＆＃34; /＆＃34; vasted＆＃34;只需更改颜色表示，您的代码将在对象检测和3D场景处理以及纹理后处理中使用。因此，您的设计标准设置为相当高的标准水平。

检查左下方窗口33,000,000 [ns] ，了解此实时管道中丢失的毫秒数。

如果您的代码的处理要求无法安全地适用于具有{ quad | hexa | octa }-core CPU资源的 many-core 时间预算，并且数字处理可能会从{ {1}} GPU资源，可能存在这种情况，Amdahl's Law may well justify用于某些异步多GPU内核处理方法，在初始/终端中丢失了额外的 +21,000 ~ 23,000 [ns] +350 ~ 700 [ns] 延迟屏蔽引入的数据传输 GPU.gloMEM -> GPU.SM.REG （很高兴具有足够的准并行线程深度图像处理的情况，即使是预期的普通GPU内核的低计算密度）
的 Ref.:
GPU/CPU latencies one shall validate initial design against:

Answer 2

不，你不能现实地做到这一点。 API没有提供它，ZeroMQ承诺接收器将获得完整的消息（包括多部分消息）或根本没有消息，这意味着它不会向接收者提供消息直到它完全转移。将数据自己拆分为可单独操作的块，这些块作为单独的ZeroMQ消息发送，这是正确的做法，在这里。