[zeromq-dev] troubleshooting

Bob SSiem socialsiem at gmail.com
Tue Oct 30 16:21:07 CET 2012

Ok, now that I'm having the issue again I'm trying to reason about the
cause.  I'm assuming that:

   - since I'm using identities to send messages to the relay
   - the connection when re-established is getting ignored because the
   original connection was not torn down correctly
   - the secret association between client server that zeromq maintains
   doesn't match because the port/IP is different or something.
   - I'm also assuming this is by design so anyone couldn't just take over
   your session by providing an identity.

So what's happening is NAT go poof, Server continues to send, but the zmq
doesn't really care about the identity I specify after it leaves the
"ROUTER".  It goes out of my view in to magic land and will never get send
because if I restart the server it will drop the queue'd messages, and if I
restart the relay it can't get resent the messages in the queue because zmq
isn't really doing anything with the "identity" at that point.

Is this a possibility what is causing my issue?  How can I mitigate?

What's odd is that I can restart the relay and happily continue from that
point in time on, the Server sends to my "identity" and the messages go
through but what happened to the messages sent while the relay was dead,
are they stuck in memory?  are they gone forever?

My guesses on mitigation.

   1. I'm using a heartbeat message, so have the relay do a full rebuild
   the connection if it han't heard anything for a few seconds.  closing the
   socket doesn't seem to help from my testing today, I think I need a new
   2. I'm trying to use a specific identity as my relay and reuse my Dealer
   Router setup.  It may work better if I use a different socket for relay
   that is identity agnostic and therefor would solve my NAT disconnection
   blackhole, but what socket types to use which would be resilient to this

If there was a way to unbind the internal mapping and reassign the
queue then I could just have the client reconnect.  I'm guessing this
wouldn't be trivial to do.  It does leave me open to someone else
impersonating the client, however this is the wild west of the intarwebs
and i'm using hmac msg authentication so I could detect an impostor.


Bob Manda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20121030/884b5b5a/attachment.htm>

More information about the zeromq-dev mailing list