ZeroMQ克隆模式和后加入客户端

Question

ZeroMQ指南在Getting an Out-of-Band Snapshot部分中描述了

  

客户端首先订阅更新，然后发出状态请求。这保证了状态将比它最早的更新更新。

如何使订阅首先保证客户端将收到比快照状态更新的所有更新？例如

1. 客户订阅状态更新
2. 客户端请求状态快照
3. 客户端收到状态快照
4. 状态更改发生在服务器上
5. 客户对状态更改的订阅已完成

因此，客户端会错过第4步中发生的状态更改。这种情况是否可能？

Answer 1

请允许我更充分地描述这个过程：

1. 服务器在发生更新时发布
2. 新客户 订阅 更新（客户SUB到服务器PUB）
3. 新客户 请求 从服务器（客户端DEALER到服务器ROUTER）的当前状态 - （ 重要 em> ：假设此请求到达服务器并开始构建快照需要更长的时间，而不是SUB套接字完成连接和订阅更新所需的时间 - 这通常是合理的假设，但请注意）
4. 服务器构建当前状态的快照以响应请求
5. 服务器继续发布更新
6. 新客户端将他们订阅的所有这些更新排队 - 尚未处理它们（这是ZMQ“免费”的一部分）
7. 服务器发回当前状态（ 重要 ：如果订阅完成后客户端的状态请求发生，则两个方案之一是的：（A）新客户加入后没有新的更新，因此状态只是新客户加入之前的历史记录，或（B）在客户端的SUB套接字中排队的状态为和的新更新。（A）非常正确，因此我们将重点关注<强>（B）即可。）
8. 新客户处理状态 - 这使其达到最新状态。
9. 新客户端开始处理SUB套接字中的消息。如果有任何我们检查它们与我们现在的历史。如果我们已经有了这个更新（来自州），我们将其丢弃。如果我们不这样做，这是一条新消息，我们会处理它。
10. 新客户端继续正常处理邮件，所有邮件都是最新的并处理所有新邮件。

...即使在示例代码中，SUB套接字在收到状态之后才开始发送recv()消息，它仍然从发布者那里获取它们并将它们排队直到它是准备好处理它们，因此没有错过更新的情况，而是计划和处理消息重复的相反情况。