Hi Joshua, I tried the TCP_KEEPALIVE, IDLE, CNT etc optiions, but it seems not work. I guess, the subscriber should reconnect the publisher if KEEPALIVE IDLE timeout (in second), however, i wait for a long time, it doesn't do it. Maybe I should get something like event on uplayer, so that I can close the previous subscriber socket and connect again, but I failed to find it...
Thanks. 2013/5/16 Joshua Foster <[email protected]> > You may also be able to use the "ZMQ_TCP_KEEPALIVE" option to help with > observation 2. > > Joshua > > 许海玲 <[email protected]> > May 15, 2013 11:05 PM > Hello zmq guys, > > I am writing this letter to confirm whether zmq PUB/SUB socket tcp > connection have no timeout mechanism. > > Recently, I am coding with ZMQ3.2.2 API. In my program, there are two > nodes, one is publisher, the other is subscriber, communicated with zmq tcp > PUB/SUB sockets. These two nodes are running on virtual machine. When the > publisher's VM is RESET(code restart), the subscriber won't received any > message from the restarted publisher. However, restart the publisher > program, reboot in guest os, disconnect interface for a period of time > won't lead to such result, subscriber always reconnects to the new started > publisher. > > With tcpdump, we noticed that > 1) restart the publisher program or reboot the guest os, makes publisher > zmq send a FIN to terminate the connection. And when publisher restarts, > subscriber will reconnect to it automatically. > > 2) Reset the VM of publisher, no FIN is sent out and when publisher > restarts, the subscribe do nothing, no communication is observed, so the > subscribe can't detect the previous connection is lost. > > 3) Reset the VM of subscriber, no FIN is sent out, and publisher is > always sending messages to the previous connection. Of course, a new > connection is established, and messages are also sent out via this > connection. > > With the above observation, we guess that zmq PUB/SUB has no connection > timeout mechanism, the connection only be terminated when one of the ends > sends a FIN. I am curious about the whether it is the design target, or a > bug. Maybe we must implements timeout with heatbeat on uplayer, to avoid > lost connection when publisher is down for power losing. > > Thanks for your information. > > Hailing. > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
