ZeroMQ可以为双向无阻塞异步传输提供基础吗? [英] Can ZeroMQ provide grounds for a bidirectional non-blocking asynchronous transmission?

问题描述

我有一个包含两个应用程序的系统.当前，两个应用程序使用针对每种特定传输类型生成的多个 ZeroMQ PUB/SUB 模式进行通信.套接字使用C编程.

I have a system which consists of two applications. Currently, two applications communicate using multiple ZeroMQ PUB/SUB patterns generated for each specific type of transmission. Sockets are programmed in C.

例如，App X 使用 SUB 正式套接字原型从App接收信息 struct Y ，并使用另一个 PUB 正式套接字原型将原始位块传输到App Y ，同样适用于App Y .它使用 PUB/SUB 模式进行发送和接收.

For example, AppX uses a SUB formal-socket archetype for receiving an information struct from AppY and uses another PUB formal-socket archetype for transmitting raw bit blocks to AppY and same applies to AppY. It uses PUB/SUB patterns for transmission and reception.

为清晰起见，App X 和App Y 执行以下通信:

To be clear AppX and AppY perform the following communications:

AppX-> AppY :
- 1 kbits 的原始位块(连续)，
-整数命令(不连续，取决于用户)

AppX -> AppY :
- Raw bit blocks of 1 kbits (continous),
- integer command (not continuous, depends on user)

AppY-> AppX :
10kbits 的信息 结构 (连续)

AppY -> AppX :
Information struct of 10kbits (continuous)

a)我的目标是在无阻塞模式下仅使用每侧只有一个套接字进行双向通信.
b)我希望两个应用程序能够处理排队的接收数据包而不会产生过多延迟.
c)我不希望AppY崩溃后AppX崩溃.

a) My goal is to use only one socket at each side for bidirectional communication in nonblocking mode.
b) I want two applications to process queued received packets without an excess delay.
c) I don't want AppX to crash after a crashed AppY.

Q1: 是否可以使用 ZeroMQ ?
第二季度: 我可以使用 ROUTER/DEALER 或其他任何方式进行这项工作吗?

Q1: Would it be possible with ZeroMQ?
Q2: Can I use ROUTER/DEALER or any other pattern for this job?

我已经阅读了指南，但无法弄清某些方面.

I have read the guide but I could not figure out some aspects.

实际上，我对 ZeroMQ 经验不足.我很高兴听到有关此问题的其他提示.

Actually I'm not well experienced with ZeroMQ. I would be pleased to hear about additional tips on this problem.

推荐答案

A1:是的，这可以通过 ZeroMQ 或 nanomsg 排序工具

ZeroMQ 和妹妹 nanomsg 都具有
Scaleable (您尚未强调)的愿景.
正式(严格的形式行为)
通信(是的，关于这个问题)
样式(经过精心雕刻，可以根据需要重新使用和组合)

A1: Yes, this is possible in ZeroMQ or nanomsg sort of tools

Both the ZeroMQ and it's younger sister nanomsg share the vision of
Scaleable ( which you did not emphasise yet )
Formal ( hard-wired formal behaviour )
Communication ( yes, it's about this )
Pattern ( that are wisely carved and ready to re-use and combine as needed )

这就是说，如果您希望每个侧面"上只有一个套接字模式，那么您必须选择这种形式模式，这样您就可以摆脱任何硬接线行为的束缚，从而满足您的目标.

This said, if you prefer to have just one socket-pattern on each "side", then you have to choose such a Formal Pattern, that would leave you all the freedom from any hard-wired behaviour, so as to meet your goal.

因此， a) "...仅一个" 是可行的-通过 zmq.PAIR (文档的某些部分将其标记为仍处于实验状态)或 NN.BUS 或一对 PUSH/PULL 您可以从只允许一个回退(事实上，这确实消除了共享 zmq.Context()实例化IO线程的所有很酷的功能，以便重新使用低端的级别的IO引擎如果您花几分钟时间阅读下面提到的示例，您很快就会意识到，当设计人员使用更多甚至更多的模式时，相反的策略是非常普遍的，并且对设计目标是有益的.系统架构.

So, a) "...only one" is doable -- by a solo of zmq.PAIR (which some parts of documentation flag as a still an experimental device) or NN.BUS or a pair of PUSH/PULL if you step back from allowing just a single one ( which in fact does eliminate all the cool powers of the sharing of the zmq.Context() instantiated IO-thread(s) for re-using the low-level IO-engine. If you spend a few minutes with examples referred to below, you will soon realise, that the very opposite policy is quite common and beneficial to the design targets, when one uses more, even many, patterns in a system architecture.

a) "... non-blocking" 是可行的，只需为各个声明正确的指令 zmq.NOBLOCK .send()/.recv()函数，并在应用程序设计体系结构中使用快速，无阻塞的 .poll()循环.

The a) "...non-blocking" is doable, by stating proper directives zmq.NOBLOCK for respective .send() / .recv() functions and by using fast, non-blocking .poll() loops in your application design architecture.

在 b)中"...没有延迟" 与对应用程序设计体系结构的特别说明有关，因为您可以仅依靠选择不当和/或无法调整事件处理程序的内部时序和延迟惩罚.如果您精心设计，您可能会完全控制系统会遇到的延迟/延迟，而不会成为任何框架黑匣子事件循环的受害者，在这种情况下，您只能等待重型系统的惊喜或交通负荷.

On b) "...without ... delay" is related to the very noted remark on application design architecture, as you may loose this just by relying on a poor selection and/or not possible tuning of the event-handler's internal timings and latency penalties. If you shape your design carefully, you might remain in a full control of the delay/latency your system will experience and not bacoming a victim of any framework's black-box event-loop, where you can nothing but wait for it's surprises on heavy system or traffic loads.

在 c)上，可以在 {ZeroMQ |nanomsg}-的基础上，通过仔细组合所有功能的非阻塞模式+通过设计使您能够在无法从预期的<接收到任何 POS_ACK 的情况下处理异常代码> {本地|远程}-功能.在这方面，可以公平地说，某些 F 正常的 C 免疫 P 电池不具有这种灵活性，这是由于某种内部强制性行为，即内部硬连线"，因此应为每个仍可扩展但具有故障恢复功能的角色选择适当的 FCP 架构.

On c) "... X crash after a Y crashed" is doable on { ZeroMQ | nanomsg }-grounds, by a carefull combination of non-blocking mode of all functions + by your design beeing able to handle exceptions in the situations it does not receive any POS_ACK from the intended { local | remote }-functionality. In this very respect, it is fair to state, that some of the Formal Communication Patters do not have this very flexibility, due to some sort of a mandatory internal behaviour, that is "hard wired" internally, so a due care is to be taken in selecting a proper FCP-archetype for each such still scaleable but fault-resilient role.

您可能会对 其他 ZeroMQ 感兴趣此处的代码>帖子和也不要错过在此引用的书链接 >>>

You might feel interested in other ZeroMQ posts here and also do not miss the link to the book, referred there >>>

这篇关于ZeroMQ可以为双向无阻塞异步传输提供基础吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！