通過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消息發送，這是正確的選擇。