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()消息，直到它接收到的状态之后，它仍然从出版商让他们和他们排队，直到它准备好处理它们，所以不会有错过更新的场景，而是计划并处理消息重复的相反场景。