ZeroMQ克隆圖案和後期加入的客戶端

Question

的ZeroMQ指南描述在Getting an Out-of-Band Snapshot節

客戶首次訂閱更新，然後使一個狀態請求。這保證了狀態將比它最早的更新更新。

如何使訂閱首先保證客戶端將接收比快照狀態更新的所有更新？例如

1. 客戶端訂閱狀態更新
2. 客戶端請求的狀態快照
3. 客戶機接收狀態快照
4. 狀態變化在服務器發生
5. 客戶對狀態變化認購完成

所以客戶端會錯過第4步發生的狀態變化。這種情況可能嗎？

Answer 1

允許我多一點全面描述了這個過程：在事件發生

新的客戶端訂閱來更新（客戶端SUB服務器PUB）

新

1. 服務器發佈更新客戶端請求當前狀態從服務器（客戶端DEALER到服務器這個假設通常是一個合理的假設，假設這個請求到達服務器需要更長的時間，並且開始構建快照，而不是直接使用SUB套接字來完成連接和訂閱更新。 ，但要注意它）
2. 服務器構建當前狀態的快照，以響應請求
3. 服務器繼續出版，因爲它們發生
4. 新客戶隊列所有他們所訂閱這些更新的更新 - 不處理他們還（這是ZMQ的一部分「免費」）
5. 服務器發回的當前狀態（重要：如果後認購完成，那麼兩種情況之一，就會發生來自客戶端的狀態請求：是（A）有新後沒有新的更新客戶端加入，所以狀態只是新客戶端加入之前的歷史記錄，或（B）有新的更新都處於狀態和在客戶端的SUB套接字中排隊。 （A）是平凡正確的，所以我們將重點放在（B））
6. 新的客戶端處理的狀態 - 這帶來它到電流。
7. 新客戶端開始處理SUB套接字中的消息。如果有任何我們檢查他們反對我們現在的歷史。如果我們已經有這個更新（來自州），我們就放棄它。如果我們不這樣做，這是一個新的信息，我們處理它。
8. 新客戶端繼續處理正常的消息，所有消息都處於最新狀態並處理所有新消息。

...即使在示例代碼中，SUB插座不啓動recv()消息，直到它接收到的狀態之後，它仍然從出版商讓他們和他們排隊，直到它準備好處理它們，所以不會有錯過更新的場景，而是計劃並處理消息重複的相反場景。