我使用zeroMQ来实现send-recv消息。我使用这种模式：PUB-SUB。
但是，似乎我可以从发布者那里发送一些消息，但是我无法从订阅者那里收到消息。这是我的代码：
//订户：
int main(int argc, char** argv){
void * context = zmq_ctx_new();
void * subscriber = zmq_socket(context, ZMQ_SUB);
zmq_connect(subscriber, "tcp:://127.0.0.1:5556");
const int SIZE = 20;
char msg[SIZE];
cout<<"receiving..."<<endl;
cout<<zmq_recv(subscriber, msg, SIZE, 0)<<endl;
cout<<"received";
zmq_close(subscriber);
zmq_ctx_destroy(context);
return 0;
}
//出版商：
int main(int argc, char** argv){
void * context = zmq_ctx_new();
void * publisher = zmq_socket(context, ZMQ_PUB);
zmq_bind(publisher, "tcp://127.0.0.1:5556");
srandom((unsigned)time(NULL));
char updateMsg[20] = "hello world";
while(1)
{
cin.get();
cout<<"sending..."<<endl;
cout<<zmq_send(publisher, updateMsg, 20, 0)<<endl;
cout<<"sent"<<endl;
}
zmq_close(publisher);
zmq_ctx_destroy(context);
return 0;
}
现在，我运营出版商然后运行订阅者 然后我在出版商处输入“Enter”，然后说：
sending...
20
sent<l
但是，在订阅者处，它始终只显示以下行：receiving...
似乎zmq_recv()被阻止了。
你能帮我吗？
答案 0 :(得分：1)
http://zguide.zeromq.org/php:chapter5#Pros-and-Cons-of-Pub-Sub
表示：
发布商无法确定订户何时成功连接，无论是初始连接还是网络故障后重新连接。
这里的要点是您的发布商首先启动，然后尽快将其消息发送到虚拟广告中。
与此同时，您的订阅者会失败，因为您的网址包含一个:太多或其他内容：
zmq_connect(subscriber, "tcp:://127.0.0.1:5556");
所以这里你去了：无数的消息无处发送，失败的订阅者没有告诉你它失败了，以及发布者没有注意到接收端没有成功连接。
答案 1 :(得分：1)
对于PUB-SUB模式，我们必须使用setsockopt为订户设置过滤器。否则，订户无法接收任何消息。因此，对于这种情况，我们应该做的是在zmq_recv之前为订阅者添加以下代码：
zmq_setsockopt(subscriber, ZMQ_SUBSCRIBE, "hello", strlen("hello"));
答案 2 :(得分：1)
PUB-SUB design 是的，ZeroMQ确实运作良好。 是的，您的代码没问题，所以麻烦在哪里？
PUB-SUB 正式沟通模式的设计是为了让PUB / publisher-side将每条消息仅分发给那些SUB 1}} / subscriber-side（s），已将自己呈现给PUB他们的个人将接收某事。这是通过所谓的订阅来完成的（在我们的人类世界中如此自然 - 你没有收到任何你没有订阅过的报纸，你可能会收到一些论文，你有。）
ZeroMQ设计反映了这种自然模式。
“新” - SUB被假定为没有（隐含地）订阅任何内容。
任何SUB都可以订阅只接收符合指定“订阅”的邮件。
任何SUB都可以订阅接收“所有内容”。
所以你的代码是按照声明的方式运行的 - 都在PUB方面（没有向一个活跃的SUB方发送任何东西，只是还没有提出任何接收内容的意愿，因此在所有，仍然坐在[ 阻止 ]等待状态中。
Nota bene ：您可能会从Pieter HINTJENS的优秀书籍中受益匪浅 - “ Code Connected，第1卷”（以PDF格式提供），其中Pieter花费很多时候解释这个伟大，智能，可扩展，无阻塞的消息库背后的概念思维。绝对值得在他的文本上花几周时间（不是代码片段，而是隐藏在那里的故事）。 确实是一本了不起的书。