具有NORM的ZeroMQ-地址已在使用中错误在第二个.bind()中引发-为什么? [英] ZeroMQ with NORM - address already in use error was thrown on 2nd .bind() - why?

问题描述

我正在将ZeroMQ与面向NACK的可靠多播(NORM) norm://协议一起使用.该文档仅包含Python代码，因此这是我的C ++代码:

I'm using ZeroMQ with NACK-Oriented Reliable Multicast ( NORM ) norm:// protocol. The documentation contains only a Python code, so here is my C++ code:

PUB 发件人:

PUB Sender :

string sendHost         = "norm://2,127.0.0.1:5556";// <NormNodeId>,<addr:port>
string tag              = "MyTag";
string sentMessage      = "HelloWorld";
string fullMessage      = tag + sentMessage;

zmq::context_t *context = new zmq::context_t( 20 );

zmq::socket_t publisher( *context, ZMQ_PUB );
zmq_connect(  publisher, sendHost.c_str() );

zmq_send(     publisher,
              fullMessage.c_str(),
              fullMessage.size(),
              0
              );

---

SUB 收件人:

---

SUB Receiver :

char   message[256];
string receiveHost      = "norm://1,127.0.0.1:5556";// <NormNodeId>,<addr:port>
string tag              = "MyTag";

zmq::context_t *context = new zmq::context_t( 20 );

zmq::socket_t   subscriber( *context, ZMQ_SUB );
zmq_bind(       subscriber, receiveHost.c_str() );
zmq_setsockopt( subscriber, ZMQ_SUBSCRIBE, tag.c_str(), tag.size() );

zmq_recv(       subscriber,
                message,
                256,
                0
                );

cout << bytesReceived << endl;
cout << message << endl;

---

我面临的问题是，根据文档两者 .bind()和 .connect()可以互换.

在我的情况下，它们都执行 .bind()，这会导致ZeroMQ抛出错误，指出由于地址已在使用中而导致第二次绑定失败.

In my case they both do a .bind(), which causes ZeroMQ to throw an error saying the second bind fails, due to address already in use error.

推荐答案

...他们两者进行绑定，这导致ZeroMQ抛出错误，提示第二个绑定失败

... they both do a bind, which causes ZeroMQ to throw an error saying the second bind fails

是的，这是一个失败的正确状态.

第一个 .bind() 获得端口的所有权"，这是排他性的角色.

Yes, this is a correct state to fail.

The first .bind() "takes ownership" of the port and this is an exclusive role.

{.bind()的可互换性|.connect()} 应该理解为哪一面 .bind() -s和哪一面 .connect() -s.

The interchangeability of { .bind() | .connect() } is to be understood so that it does not matter which side .bind()-s and which one .connect()-s.

直到这一刻，我还没有人以这样一种方式来解释此属性，即双方都将尝试 .connect()(不存在的 .bind()-(非暴露的访问点)，尝试 .bind()一个已经占用"的端口(如果驻留在同一本地主机上)或保留在nox-et-solitudo状态，对于 .bind() -s中的任何一个在不同本地主机上的两个端口上都建立了这样的 .connect() -ready状态的情况-s，此后两者都保持沉默(永远)，因为(并且将)不会尝试使任何 .connect() -ion正常运行.

Until this moment, I saw no one interpreting this property in such a manner, that both sides would try to .connect() ( a non-existent .bind()-(not)-exposed Access Point ), the less to try to .bind() an already "occupied" port ( in case of residing on the same localhost ), or to remain in a nox-et-solitudo state, for the cases that either of the .bind()-s establishes such a .connect()-ready state on both ports on different localhost-s, which both after that remain in a silent solitude ( forever ), as there is ( and will be ) no attempt to make any .connect()-ion going live and operational.

不，您只需要 1 .bind()，此后可能会处理 0+ 未来的 .connect()请求，并为任何相应的 <建立实时频道 PUB/SUB ; transport-class> 协议，包括新添加的 norm:// .

No, you need just 1 .bind(), that may since that moment handle 0+ future .connect()-requests, arriving to establish a live-channel PUB/SUB, for any respective <transport-class> protocol, including the newly added norm://.

无论如何，欢迎 norm:// 加入ZeroMQ协议族.

可能享受 5秒钟再阅读
关于 [不到五秒钟的ZeroMQ层次结构] 中的主要概念差异和讨论 此处 .

May enjoy a further 5-seconds read
about the main conceptual differences in [ ZeroMQ hierarchy in less than a five seconds ] or other posts and discussions here.

这篇关于具有NORM的ZeroMQ-地址已在使用中错误在第二个.bind()中引发-为什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！