This sounds like this problem:
http://www.evanjones.ca/tcp-stuck-connection-mystery.html (tl;dr
version: the final ack packet gets lost when establishing the connection
but the loss doesn't get detected until actual data is sent).
AFAIK 0mq doesn't do heartbeating on its own, so it can't detect this
situation without extra user code.
Regards,
Attila Balazs
[email protected] said:
21.01.2012 01:56, Sergey Matveychuk wrote:
clients. netstat -a on server shows no connection with a client, but on
the client netstat -a shows an established connection:
I think the patch will resolve my problem.
As Martin Sustrik says, SO_KEEPALIVE is probably not what you want. You can
do heartbeating/keep-alive at the application level instead.
--- src/ip.cpp.orig 2012-01-22 15:17:01.000000000 +0400
+++ src/ip.cpp 2012-01-22 15:21:21.000000000 +0400
@@ -49,6 +49,13 @@
if (s == retired_fd)
return retired_fd;
+ // Turn keep-alive on for TCP
+ if (protocol_ == IPPROTO_TCP) {
+ int optval = 1, optlen = sizeof(int);
+ int rc = setsockopt (s, SOL_SOCKET, SO_KEEPALIVE,&optval, optlen);
+ errno_assert (rc != -1);
+ }
+
// If there's no SOCK_CLOEXEC, let's try the second best option. Note
that
// race condition can cause socket not to be closed (if fork happens
// between socket creation and this point).
open_socket() is not the right place to put this. I'd probably add a
keepalive_socket() and call that in the same places from where
stream_engine_t calls unblock_socket().
-mato
_______________________________________________
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
