是否可以使用＆＃34;锁定＆＃34; ZeroMQ中的主题，以便向新加入的订阅者重复发送到主题的最后一条消息？
目前我必须在 REQ-REP 对之外创建一个 PUB-SUB -socket对，以便在新< strong> SUB 加入，它会使用 REQ -socket请求最后一条消息。但这项额外的工作，都是模板，非常不受欢迎。
ROS有＆＃34;已锁定＆＃34;选项，它被描述为：
锁定连接后，将保存发布的最后一条消息 自动发送给任何未来连接的用户。这是 对于缓慢更改为静态数据（如地图）非常有用。请注意，如果有 是同一主题的多个发布者，在同一主题中实例化 节点，然后只有该节点的最后发布消息 已发送，而不是每个发布者发布的最后一条消息 那个单一的主题。
答案 0 :(得分：1)
鉴于历史记录中的一些内容，由于分布式计算性能和内存容量原因以及流量成本低，主题过滤器最初是在 SUB 上实施的 - 一方（s），而后期版本开始在 PUB 旁边运行此功能。
因此，您的应用程序将永远不会知道哪些客户端将使用哪个版本的ZeroMQ，而问题主要是无法解决的。
说完了，
您的应用用户代码在 PUB 旁边可以解决此问题，发送二合一格式的消息，以及 SUB 可以让-side知道嵌入到消息流中的这种软逻辑。
只需实现＆＃34;锁定＆＃34;用户代码中的逻辑，可以通过每个主题行或其他方式对每条消息进行天真的重新发送。
不是 PUB/SUB 可扩展的正式通信模式原型 - 有两个原因 - 它不是任何通用的，普遍适用的行为，而是用户特定的专业 - 加上 - - 主题过滤器（无论是 PUB -side还是 SUB - 经营）还没有关于词汇分支的先验知识（订阅是词汇从左到右解释，没有人可以先验地说，下一个订阅者实际订阅了什么，因此一个＆＃34;锁定＆＃34; -last-message存储将无法获得预先填充，直到新的＆＃34; next＆＃34;订阅者实际加入并设置其实际的主题过滤器订阅（存储所有确定性，组合学驱动，可能的{sub- | super - } - 主题选项是一个非常糟糕的想法，以规避主要的不可判定性，不是吗？））