是否可以在通过 UDP 发送数据时将数据流式传输到 ZeroMQ 消息中？
Is it possible to stream data into a ZeroMQ message as it is being sent via UDP?
我们正在 30fps 处理延迟关键型应用程序，管道中有多个阶段（例如压缩、网络发送、图像处理、3D 计算） 、纹理共享等）。
通常我们可以像这样实现这些多个阶段：
[Process 1][Process 2][Process 3]
---------------time------------->
但是，如果我们可以堆叠这些过程，那么可能 [Process 1] 在处理数据时，会不断将其结果传递给 [Process 2]。这类似于 iostream 在 C++ 中的工作方式，即 "streaming"。使用线程，这可以减少延迟：
[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）将消息的部分内容设为 'under construction' 或 'constructed on demand'？这在接收方是否也可能（即允许在消息的开头采取行动，因为消息的其余部分仍在传入）。或者.. 是我们自己手动将数据拆分成更小块的唯一方法吗？
Note:
计算机 A 和 B 之间的网络连接是直线 GigE 连接。
不，你做不到。 API 没有提供它，ZeroMQ 承诺接收者将收到完整的消息（包括多部分消息）或根本没有消息，这意味着它不会将消息呈现给接收者直到完全转移。在这里，将数据自己拆分为单独的可操作块，作为单独的 ZeroMQ 消息发送是正确的做法。
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 ) 设计 处理阶段
2 ) BENCHMARK 每个阶段的实施模型
3 ) PARALLELISE 只要 Amdahl's Law says 有意义且可能
如果您的代码允许并行处理，您的计划将更好地利用 "progressive"-管道处理，并使用 ZeroMQ 零-复制/（几乎）零-延迟/零-阻塞可在inproc: 传输 class 并且您的代码可能支持 "progressive"-在多个处理阶段之间进行流水线操作。
请记住，这不是单行代码，不要期望 SLOC 来控制您的 "progressive"-流水线制作。
[ns] 问题，请仔细阅读数据处理微基准中的数据。
它们确实决定了你的成功.
在这里，您可能会看到 "lost" / "vasted" 仅更改颜色表示需要多少时间，您的代码在对象检测和 3D 场景处理以及纹理 post 处理中将需要这些时间。因此，请将您的设计标准设置为相当高的标准水平。
检查 左下方 window numbers 在此实时管道中丢失的毫秒数。
如果您的代码的处理要求不能完全符合您的 33,000,000 [ns] 时间预算和 { quad | hexa | octa }-core CPU 资源，并且如果数字处理可能受益于 many-core GPU 资源，可能存在这样的情况，即 Amdahl's Law may well justify 对于一些异步多 GPU 内核处理方法，它们的附加 +21,000 ~ 23,000 [ns] 在 initial/terminal 数据传输中丢失 +350 ~ 700 [ns] 由 GPU.gloMEM -> GPU.SM.REG 延迟掩码引入（很高兴 具有 在您的图像处理情况下有足够的准并行线程深度，即使对于预期的普通 GPU 内核的低计算密度也是如此）
Ref.:
GPU/CPU latencies one shall validate initial design against:
我们正在 30fps 处理延迟关键型应用程序，管道中有多个阶段（例如压缩、网络发送、图像处理、3D 计算） 、纹理共享等）。
通常我们可以像这样实现这些多个阶段：
[Process 1][Process 2][Process 3]
---------------time------------->
但是，如果我们可以堆叠这些过程，那么可能 [Process 1] 在处理数据时，会不断将其结果传递给 [Process 2]。这类似于 iostream 在 C++ 中的工作方式，即 "streaming"。使用线程，这可以减少延迟：
[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）将消息的部分内容设为 'under construction' 或 'constructed on demand'？这在接收方是否也可能（即允许在消息的开头采取行动，因为消息的其余部分仍在传入）。或者.. 是我们自己手动将数据拆分成更小块的唯一方法吗？
Note:
计算机 A 和 B 之间的网络连接是直线 GigE 连接。
不，你做不到。 API 没有提供它，ZeroMQ 承诺接收者将收到完整的消息（包括多部分消息）或根本没有消息，这意味着它不会将消息呈现给接收者直到完全转移。在这里，将数据自己拆分为单独的可操作块，作为单独的 ZeroMQ 消息发送是正确的做法。
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 ) 设计 处理阶段
2 ) BENCHMARK 每个阶段的实施模型
3 ) PARALLELISE 只要 Amdahl's Law says 有意义且可能
如果您的代码允许并行处理，您的计划将更好地利用 "progressive"-管道处理，并使用 ZeroMQ 零-复制/（几乎）零-延迟/零-阻塞可在inproc: 传输 class 并且您的代码可能支持 "progressive"-在多个处理阶段之间进行流水线操作。
请记住，这不是单行代码，不要期望 SLOC 来控制您的 "progressive"-流水线制作。
[ns] 问题，请仔细阅读数据处理微基准中的数据。
它们确实决定了你的成功.
在这里，您可能会看到 "lost" / "vasted" 仅更改颜色表示需要多少时间，您的代码在对象检测和 3D 场景处理以及纹理 post 处理中将需要这些时间。因此，请将您的设计标准设置为相当高的标准水平。
检查 左下方 window numbers 在此实时管道中丢失的毫秒数。
如果您的代码的处理要求不能完全符合您的 33,000,000 [ns] 时间预算和 { quad | hexa | octa }-core CPU 资源，并且如果数字处理可能受益于 many-core GPU 资源，可能存在这样的情况，即 Amdahl's Law may well justify 对于一些异步多 GPU 内核处理方法，它们的附加 +21,000 ~ 23,000 [ns] 在 initial/terminal 数据传输中丢失 +350 ~ 700 [ns] 由 GPU.gloMEM -> GPU.SM.REG 延迟掩码引入（很高兴 具有 在您的图像处理情况下有足够的准并行线程深度，即使对于预期的普通 GPU 内核的低计算密度也是如此）
Ref.:
GPU/CPU latencies one shall validate initial design against: