ZeroMQ不会自动重新连接 [英] ZeroMQ doesn't auto-reconnect

问题描述

我刚刚在Unbutu Precise(12.04)系统上下载并安装了zeromq-4.0.5.我已经编译了hello-world client ( REQ ，连接127.0.0.1)和

I've just downloaded and installed zeromq-4.0.5 on an Unbutu Precise (12.04) system. I've compiled the hello-world client (REQ, connect, 127.0.0.1) and server (REP, bind) written in C.

1. 我启动服务器.
2. 我启动客户端.
3. 客户端每秒向服务器发送一条消息，并收到响应.
4. 我按Ctrl- C 停止服务器.
5. 客户端尝试发送其下一个外发消息，并且卡在永不返回的 epoll 系统调用中(如 strace 所示).
6. 我重新启动服务器.
7. 即使新服务器已运行一分钟，客户端中的zmq_recv调用仍会停留.为客户端取得进展的唯一方法是杀死它(使用Ctrl- C )并重新启动它.

1. I start the server.
2. I start the client.
3. Each second the client sends a message to the server, and receives a response.
4. I press Ctrl-C to stop the server.
5. The client tries to send its next outgoing message and it gets stuck in an never-returning epoll system call (as shown by strace).
6. I restart the server.
7. The zmq_recv call in the client is still stuck, even when the new server has been running for a minute. The only way to make progress for the client is to kill it (with Ctrl-C) and restart it.

问题1:这是预期的行为吗??我希望客户端 应该 会在几秒钟内发现服务器处于运行状态.再次运行，它将自动重新连接.

Q1: Is this the expected behavior? I'd expect that in a few seconds the client should figure out that the server is running again, and it would auto-reconnect.

问题2:我应该在示例代码中进行哪些更改以解决此问题?

问题3:我使用的软件版本错误，还是系统上出现了问题?

我已禁用防火墙，sudo iptables -S打印-P INPUT ACCEPT; -P FORWARD ACCEPT; -P OUTPUT ACCEPT.

I've disabled the firewall, sudo iptables -S prints -P INPUT ACCEPT; -P FORWARD ACCEPT; -P OUTPUT ACCEPT.

在strace -f ./hwclient输出中，我可以看到服务器关闭后，客户端正在每秒尝试connect() 10次(默认值ZMQ_RECONNECT_IVL).在strace -f ./hwserver输出上，我可以看到重新启动的服务器accept()建立了连接.但是，此后通信陷入僵局，服务器从不接收来自客户端的实际请求(但是它会通知我何时杀死客户端；服务器还会从服务器重启后启动的其他客户端接收请求).

In the strace -f ./hwclient output I can see that the client is trying connect() 10 times a second (the default value of ZMQ_RECONNECT_IVL) after the server went down. On the strace -f ./hwserver output I can see that the restarted server accept()s the connection. However, communication gets stuck after that, and the server never receives the actual request from the client (but it notices when I kill the client; also the server receives requests from other clients which have been started after the server restart).

使用ipc://代替tcp://会导致相同的行为.

Using ipc:// instead of tcp:// causes the same behavior.

如果在客户端执行下一个zmq_send之前服务器已被终止，则自动重新连接会成功在zmq_send中进行.但是，如果在客户端运行zmq_recv时服务器被杀死，则zmq_recv会无限期阻塞，并且客户端似乎无法从中恢复.

The auto-reconnect happens in successfully in zmq_send if the server has been killed before the client does the next zmq_send. However, when the server gets killed while the client is running zmq_recv, then the zmq_recv blocks indefinitely, and the client can't seem to recover from that.

我找到了这篇文章，建议使用超时.但是，我认为超时不是正确的解决方案，因为TCP断开连接通知已在客户端进程中提供，并且已经在起作用，它只是不会使zmq_recv将请求重新发送到新的服务器-或至少提前返回以指示错误.

I've found this article, which recommends using timeouts. However, I think that timeouts can't be the right solution, because the TCP disconnect notification is already available in the client process, and it's already acting on it -- it just doesn't make zmq_recv resend the request to the new server -- or at least return early indicating an error.

推荐答案

您可能会遇到与zemomq在4.0.6中为我解决的问题相同的问题(

You may having the same issue that zemomq just fixed for me in 4.0.6 (issue 1362). Basically, the subscriber socket wouldn't always resend it's filter back over during a reconnection (an empty filter means no messages from publisher to that subscriber). The only way to recover was to restart the client's application. Their fix seems to have done the job. The issue was really highlighted when using a transport (like stunnel) to tunnel the connections. Without 4.0.6, I was able to get around the issue by setting the "immediate" flag on the subscriber socket.

这篇关于ZeroMQ不会自动重新连接的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！