ZeroMQ中的闭锁主题

Question

在ZeroMQ中是否可能有一个“锁定”主题，以便将发送到该主题的最后一条消息重复给新加入的订阅者？

目前，除了REQ-REP-socket对之外，我还必须创建一个PUB-SUB对，这样当新的SUB加入时，它会使用REQ-socket.请求最后一条消息。但这项额外的工作，都是样板，是非常不受欢迎的。

ROS有“闩锁”选项，它被描述为：

当连接被锁定时，最后发布的消息将被保存并自动发送到任何未来的连接订户。这对于像地图这样的缓慢转换为静态数据是有用的。注意，如果同一主题上有多个发布者，并在同一个节点中实例化，那么将只发送来自该节点的最后一次发布的消息，而不是每个发布者在该主题上最后发布的消息。

Answer 1

那么，您的想法在ZeroMQ中是可行的：

从历史上看，由于分布式计算性能和内存容量的原因以及通信量的低成本，主题筛选器最初是在SUB-side(s)，上实现的，而后来的版本则开始在PUB-side.上操作这个特性。

因此，您的应用程序将永远不会事先知道哪些客户端将使用哪个版本的ZeroMQ，问题主要是无法确定的。

这么说，

您的应用程序用户代码，在PUB-side，上可以解决这个问题，发送2/1格式的消息，并且您的SUB-side可以知道嵌入到消息流中的这种软逻辑。

只需在用户代码中实现“闭锁”逻辑，无论是通过简单的每条主题行的每条消息的重新发送，还是其他一些方法。

是的，只有用户代码能处理这件事，

不是PUB/SUB可扩展的正式通信模式原型--出于两个原因--它不是任何一般的、普遍适用的行为，而是特定于用户的特定特性--加上--主题过滤器(不管是PUB-side还是SUB-side操作的)对词法分支没有事先的知识(订阅是从左到右的词汇解释，而且没有人能够先验地说，下一个订阅者实际上会订阅什么，因此，在新的"next“订阅者实际加入并设置其实际的主题过滤器订阅(存储所有确定性的、组合器驱动的、可能的{ subscription选项)之前，”闭锁“最后消息存储将无法预先填充，不是吗？