用于进程间通信的ZeroMQ套接字类型应该使用哪种？

Question

用于进程间通信的ZeroMQ套接字类型应该使用哪种？

8

当我只有两个线程时，我使用了PAIR套接字类型。但现在我正在使用两个进程，它们可以位于同一台机器上，也可以位于不同的机器上。我不需要请求和响应，也不需要向多个节点发送数据等。我需要与PAIR相同的东西（异步、双向），但是需要使用进程和网络。我应该使用哪种套接字类型？

- Marko Kevac

2个回答

1

@Marko提醒我注意，

ZMQ.SOCKET（正式通信模式）的"type"和任何一种传输方式之间存在主要分离，无论您选择使用哪种传输方式.bind() / .connect()

一旦您的架构（如您所写）可以与PAIR/PAIR "会话"一起工作

您只需更改要使用的传输方式，而不需要进行单个附加SLOC更改

它能够正常工作

Python 2.7.3 ...
>>> import zmq
>>> zmq.zmq_version()
'2.1.11'
>>> aZmqCONTEXT =  zmq.Context()                       # --<BoCTX>-- [SideA] Node
>>> aZmqSOCKET  = aZmqCONTEXT.socket( zmq.PAIR )       # here one decides about a type
>>> aZmqSOCKET.bind( "tcp://192.168.0.62:2027" )       # here is the transport // used to be ( "ipc://...")
>>> aZmqSOCKET.recv()                                  # here the PAIR waits for 1st MSG
'aMSG from the opposite PAIR/PAIR zmq-session Node arrived via TCP-transport ... QED'
>>> aZmqSOCKET.setsockopt( zmq.LINGER, 0 )             # pre-termination tidy-up
>>> aZmqSOCKET.close()
>>> aZmqCONTEXT.term()                                 # --<EoCTX>-- safe to clean-exit
>>>

- user3666197

在ZeroMQ文档中明确指出PAIR仅适用于inproc。我不知道为什么在你的情况下它能够工作。https://www.dropbox.com/s/he8rkzds98am4p1/Screenshot%202014-06-14%2011.14.03.png - Marko Kevac

@MarkoKevac 感谢反馈--然而，文本确实说：“...设计用于：//inproc”(因为PAIR/PAIR抽象模式在无堆栈进程间通信领域表现最佳)，但是它并没有任何关于不能绑定(connect)到其他支持传输类别的字眼，也不禁止这样做。当然，在将缓冲块传递给另一个< _localhost_ >进程时，花费[usec]来喂饱TCP/IP堆栈是可能的，但它浪费了时间和资源，所以在这里：//inproc表现最佳。 - user3666197

1

作为一个更一般的注意事项，这种经验使得抽象丰富的正式通信模式的概念更加明显，这是 ZeroMQ / nanomsg 背后最令人兴奋和强大的“黑质量”惊喜，它并不总是被看到、理解和利用以实现这些伟大工具的最佳效果。值得阅读这本书，先从图中的想法拍照，然后再进行设计草图，最后才编写源代码。无论传输是否可知，容错并行负载平衡都不会从单独的源代码行中得到理解。 - user3666197

PAIR套接字不会自动重新连接，这可能会带来问题。尽管ZMQ_PAIR套接字可以在除了zmq_inproc(7)之外的传输方式上使用，但它们无法自动重新连接，并且在存在任何先前连接（包括处于关闭状态的连接）时，新的传入连接将被终止，这使得它们在大多数情况下不适用于TCP。 - YouJiacheng

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Jason · Accepted Answer

很遗憾，您的世界变得更加复杂了。在更广泛分布的系统中，没有直接对应 PAIR/PAIR 套接字配对的模拟。

话虽如此，如果您保持大致相同的拓扑结构形状（两个节点互相连接而不连接其他节点），那么您就可以使用 ROUTER/DEALER ，甚至是 DEALER/ DEALER （正如您在评论中建议的那样）来实现您想要的东西。这些套接字有点类似于 REQ/REP ，但它们不强制要求严格的请求/响应通信模式，它们完全没有限制，因此实际上您获得了相同的效果。唯一的问题是，如果您想要添加更多节点，则必须开始以稍微不同的方式进行管理，特别是 DEALER 套接字不允许您选择发送到哪个节点，它严格按照轮询方式处理。

但是，这样做应该可以满足您的需求（异步，双向）。 ROUTER 套接字类型可能需要额外的复杂性，因为您需要跟踪另一个节点的“标识符”才能将消息发送回它（您可以从发送的消息中直接获得这个标识符，尤其是在您只有一个对等点的情况下，几乎可以免费使用）。由于这是一个独占对，您可以忽略 DEALER 套接字引入的轮询不确定性，并直接使用 DEALER/ DEALER ，它为您提供了不受限制的消息模式，并且不需要管理任何标识。