1

就像这个操作看起来一样简单，我找不到任何关于如何使用 ZMQ (Jeromq) 接收多部分消息的文档。我检查了指南，但它只包含带有此信息的 C 代码，而且无论我收到什么类型的消息，我似乎都应该以相同的方式接收消息。

实际上，我使用以下代码在两条消息中收到多部分消息：

while (running.get()) {
    items.poll();
    if (items.pollin(0)) {
        ByteArray message = receiver.recv(0);
        System.out.println("Received " + String(message, Charset.forName("UTF-8")));
    }
}

如果我发送这样的多部分消息，“已接收”部分将被打印两次：

publisher.sendMore(message.key);
publisher.send(objectMapper.writeValueAsString(message.data));

我究竟做错了什么？

编辑：C我知道示例下方有一个语言选择器，但是在任何仅与代码内联解释的示例中都不存在此特定问题。

编辑

我试图探索 API 并找到了hasReceiveMore()方法。我尝试使用它，但它没有用，我最终使用以下代码进行了无限循环：

List<String> parts = new ArrayList<>();
while(receiver.hasReceiveMore()) {
    parts.add(receiver.recvStr());
}
4

1 回答 1

-1

问：“我做错了什么？”

您的代码必须主动假设每条消息可能已被组合为多部分消息（在此为零保证，先验较少）并ZMQ_RECVMORE在每个后续 -method 调用之后主动检查标志的存在.recv()，直到.getsockopt( ZMQ_RECVMORE )-method 另有说明。

JeroMQ 可能已将此已发布的本机 API 转换为其他一些实用方法，因此最好重新阅读 JeroMQ 源代码以查找此本机 API 多部分消息处理“协议”被包装到 JeroMQ 工具中的位置。

结语: Verba docent, Exempla trahunt...

在帮助了超过 130 万社区成员和无数匿名网站访问者后，我因提供帮助而受到惩罚和审查。

删除评论的审查仍在继续。StackOverflow 的精神转向数字极权主义。删除，删除和惩罚那些一直在思考并向那些寻求赞助帮助的人提供帮助和建议的人......
------------------------ --------------
让我们回顾一下事实：
-----
“我找不到任何关于我应该如何接收零件的文档，但我尝试了一些看起来像你提到的东西......它也没有工作。 – Adam Arold 20 小时前“

没有找到“任何文档”或“不工作”（另一个未发布的、可重现的 MCVE）是我的错或遗漏，是吗？

（我对这些虚假声明的回答在发布几分钟后被行政删除......不言自明）
-----
“这不是一个答案，它不包含解决方案。我不知道你为什么'很惊讶。你引用的是与 JeroMQ API 无关的 C API。最后的解决方案是recv在我尝试检查RECVMORE标志之前我必须这样做。这不在你的答案中。或者ZMsg可以使用. – Adam Arold 11 小时前“


索赔分析：

第 1 句。：

“这不是答案，也不是”

这是一个答案，尽管有“索赔”。它包含几条重要的信息，否则她/他/任何人将不得不尝试寻找数小时（数天或数周？）以便以后学习并在概念上很好地理解架构，以免产生任何格式错误的代码-设计或主要陷入自己的、误解的决定中Sustrik 的杰作 - ZeroMQ，自 v2.1+ 起。所以这种“说法”既错误又没有事实依据。一个小的“声称”答案不包含解决方案是荒谬的，StackOverflow 社区成员既不是要大喊大叫的员工，

句子＃2：（

表达的感觉）
-宁可跳过，因为它更像是一种侮辱而不是公平的争论，不是吗？

句子#3：

“您引用的是与 JeroMQ API 无关的 C API。”

哦，当然，是的，C API（以及关于任何对等实现必须遵守的强制性“有线”协议属性的 ZeroMQ-RFC 文档......）是所有这一切的起点和主要参考。没有_，已发布的 ZeroMQ RFC 文档和 API 都是任何人开始使用的坚如磐石的参考，以便更好地理解内部引擎和所有遵守协议泵的强制性“有线”属性是如何工作的（以及必须工作），以便声明自己保留 ZeroMQ 兼容性。JeroMQ 的作者是根据这些记录在案的属性进行工作的，不是吗？如果他们不这样做，或者如果他们在这样做时“偷工减料”，那么故事就丢失了，这不是我的错，他们没有满足和/或涵盖所有 ZMTP/ZeroMQ-RFC/API 属性和要求，是吗？也就是说，任何包装器/绑定，包括任何版本的 JeroMQ 也必须符合这些内部工作规则，如果没有其他地方，这些内部工作规则已经充分自我记录和演示，在 JeroMQ 源代码中（哪个警告也是提供的答案的一部分，不是吗？），如果它渴望成为与 ZeroMQ 兼容的工具。同样，如果您当前（使用过的）JeroMQ 实现未能满足您想要使用和通读的有据可查的 JeroMQ-API 文档（到找到用例的代码的描述和示例），声称它没有或想要寻找和找到任何此类（源代码）信息的意愿，社区赞助成员不会因缺乏而受到惩罚前者多，后者多。

句子 4. + 5. ：

这需要突出显示：

“最终的解决方案是我必须recv在尝试检查RECVMORE标志之前。这不在你的答案中。”

首先，它出现在答案中——第一句话：
“......代码必须主动假设每条消息可能是作为多部分消息组成的（这里的零保证，先验越少）和主动检查是否存在ZMQ_RECVMORE标记，在每个后续.recv()的 -method 调用之后，直到.getsockopt( ZMQ_RECVMORE )-method 另有说明。”


我这一代人从小就坚信，如果我们犯了错误或做出了错误的决定，基于一个不受支持的假设，我们永远不会惩罚任何人，因为（我们）做出了错误的决定。令人惊讶的是，没有在这里工作。为什么有人会惩罚一个伸出手来帮助你解决问题并支持你个人需要更进一步的人？如果寻求赞助帮助并惩罚任何这样做的人的文化会进一步发展，那么没有人会愿意。这不是所谓的傲慢或独裁者的人与人之间的行为吗？无论是前者还是后者，都不公平，推广的风格越少，作为社区首选行为的回报就越少。“参数”本身是空的，无效的 - 没有调用.recv()-method，从 ZeroMQ-API 抽象范围内什么都得不到，越少的指示，承诺通过.getsockopt()-method 在获取RECVMORE-flag 时的使用来学习（当然，经过一番.recv()已被确认获得了一个实质——消息——这既是基本的，也不需要在任何关于 ZeroMQ/JeroMQ 消息传递的文本中“包含”它，因为它是不言自明的——有人会声称这是不公平的不是解释如果到目前为止没有发送电子邮件，要求电子邮件附件是没有意义的吗？没有一个公平的会。所以，Answer 的做法恰恰相反——它确实警告过这一点，即对于每一个.recv()-ed 消息，专业设计师应该总是假设一个{ 0+ }-RECVMORE标记的多部分消息组件，它遵循第一个.recv()-ed 并且需要被挖掘出来API 的。

最后一句：

“Alternatively ZMsgcan be used”。

此声明仍然是一个无法确定的问题，因为 O/P 包含有关版本的零信息。原生 ZeroMQ API 自通过 v2.0-v2.1-..-v2.11、v3.0-v3.1-v3.2 首次发布以来已经发展，通过 v4.0-v4.1- 重构和扩展v4.2-v4.3 并且仍在计数，并且“已声明”的Zmsg抽象肯定不会出现在早期的实现中，因此版本号对此至关重要（也是 StackOverflow 关于如何询问的最佳实践的一部分关于重现问题的 MCVE / MWE 代码和所有相关细节的好问题，版本号是其中的一部分，不是吗？）。

于 2020-10-04T10:36:25.497 回答