The documentation just states that this event occurs when a connection is
disconnected ‘unexpectedly’.
It would be useful, simply from a logging point of view, to be able to know WHY
the session got disconnected.
Certain error codes imply certain network troubleshooting steps, for instance.
Wo
I put together the following program to show the issue. It seems if the option
ZMQ_IPV4ONLY is set to 0 (to enable IPV6), then ZMQ as running on OS X allows
two sockets to bind to the same port, provided the address used is 0.0.0.0. For
instance, as in the test program, I can construct two socke
I’m curious about the answer here myself, since our use case is similar. Since
there don't seem to be any explicit notifications that a client connects or
disconnects (outside the ZAP interface when negotiating security), we are
thinking of using some type of sliding window and DEALER/ROUTER so
ection is established the LT keys aren't used again.
> This is inherent in the CurveZMQ design. You could and would normally
> force all connections to end, by restarting the server.
>
>
> On Tue, May 20, 2014 at 2:44 AM, Keith Henrickson
> wrote:
>> Presently once
Presently once the server socket is bound, the keys can never change, as
they’re not read from the socket options again.
Not a bad idea, but I’m wondering if that would ever change? Would the
server-side ever be changed to read the keys from the options upon each
connection?
If the server keys
