我试图在指南中运行ZeroMQ PUB/SUB - python中的原型示例（wuserver，wuclient），但这对我不起作用。
我在Ubuntu VM上尝试过它。我在python3.6.1（在VM中）pyzmq.__version__ == 16.0.3上运行ubuntu 16.10。如果我改变套接字＆＃39;从PUB/SUB到PUSH/PULL的原型，客户端开始按预期获取消息。
我在SUB - 服务器之前启动了PUB - 客户端（我已经尝试了相反的方式），但SUB从未收到任何消息。
答案 0 :(得分：1)
这个例子实际上是开箱即用的。我注释掉socket.setsockopt_string(zmq.SUBSCRIBE, zip_filter)而不是为zip_filter提供空字符串，并且不允许套接字接收任何内容。我没有意识到setsockopt_string电话的重要性。
答案 1 :(得分：0)
定义ZeroMQ原型以表示某种行为。如上所述，PUSH - 原型AccessPoint推送每条消息＆＃34;通过＆＃34;所有到目前为止设置的通信信道，PULL - 或者AccessPoint将已经到达线路的所有内容拉到＆＃34;它的手＆＃34;，PUB - lisher AccessPoint发布，SUB - scriber AccessPoint订阅，以便只接收与其主题过滤器匹配的消息，但不接受任何其他消息。
似乎很清楚，这样的Archetype＆＃34;规范＆＃34;有助于构建ZeroMQ智能消息/信令基础架构，以便在distributed-systems架构中轻松使用。
根据定义，刚刚实例化的 SUB -side AccessPoint对象几乎没有机会知道什么是正确的消息的选择，所以他们应该被交付＆＃34;什么消息不是。
如果没有这一初步知识，ZeroMQ设计师有一个主要选择要么 Archetype-policy一致，让PUB - 侧AccessNode分配所有.send() - 仅通过SUB - 机制或明确要求接收任何此类权限的zmq.SUBSCRIBE方AccessNode获取的消息，以传递从PUB发送的所有内容{1}}到目前为止还没有决定SUB - s。
前者是ZeroMQ作者的一贯而专业的设计步骤 后者实际上意味着违反ZeroMQ自己的RFC规范。
后者的选择就像是如果一个人刚搬到一个新的公寓，人们几乎没想到会发现所有的报纸和杂志从第二天早上出现在一个新的邮箱中，是吗？但是，如果有人订阅波士顿环球报，那么第二天早上新的发布将在门口，因为它仍将存在，直到一个取消订阅或报纸破产或缺乏纸卷阻止印刷厂交付在适当的时间和时尚或Big Dig隧道的交通堵塞可能会导致所有人或仅在某一天的当地交付时遇到麻烦。
这一切都很自然，并且与Archetype政策兼容。
<子> 间奏曲：
技术纯粹主义者会在此反对，早期的API版本（直到某些v3.2 +）实际上在技术上将所有消息有效负载从PUB传输到所有SUB - s，因为它简化了{{1} } - 工作负载包络，但增加了传输类数据流和PUB - 侧资源/延迟主题 - 过滤处理。然而，所有这一切都隐藏在用户代码中，正是API抽象的视界。因此，除了需要适当地扩展资源之外，这对用户来说是透明的。更新的API版本恢复了主题过滤器处理器的作用，现在让它发生在SUB侧。然而，在这两种情况下，ZeroMQ RFC规范策略都是以这种方式实现的，PUB - 方将永远不会（通过SUB - 接口）传递一条与有效信息不匹配的消息。 ，明确的.recv() - 边订阅
在所有情况下，SUB - 方尚未明确设置任何SUB - 指示的主题过滤器，它不能并且不会提供任何内容（这两者都是自然的并且与为zmq.SUBSCRIBE类型的AccessPoint定义的ZeroMQ RFC Archetype-policy完全一致。
至少，请务必阅读ZeroMQ API文档，其中所有细节都经过专业指定 - 至少，人们可以第一眼看到智能消息/信令框架的气息。
这无助于任何人开始绿色领域并完全构建自己复杂的心理概念，并深入理解所有内容如何在内部工作，这显然不是任何API文档和＃39的野心，是吗？然而，一旦掌握了ZeroMQ内部架构，这将有助于任何人刷新或提醒所有可配置的细节，详见下文中提到的源代码。
另外，对于确实对distributed-systems或zeromq本身感兴趣的任何人来说，值得花时间和精力来永远阅读Pieter HINTJENS＆＃39;书＆＃34;代码连接，第1卷＆＃34; （以PDF格式免费提供）以及他之后关于他在软件工程方面丰富经验的任何其他书籍，因为他对现代计算的许多见解可能并且将激发（和很多）。