[zeromq-dev] CZMQ socket event monitor

Pieter Hintjens ph at imatix.com
Mon Oct 28 01:37:31 CET 2013

Hi Chris,

That's really nice! Would you send that as a pull request to CZMQ? If
I can suggest a name change, call it zmonitor, simpler and easier to

The problem of reconnecting was one of the things I solved in Zyre,
which does group messaging though a little different than pub-sub.
Mainly it aims to not lose messages when a subscriber disconnects and
reconnects on a new address, something that happens frequently on
loaded WiFi networks.

To make this work you need a two-way flow for heartbeating and
metadata exchange, once you do that you might as well use the same
sockets for message transfer.

Any reason you can't use Zyre?


On Mon, Oct 28, 2013 at 12:34 AM, Chris Laws <clawsicus at gmail.com> wrote:
> A while back I saw mention of someone wanting access to the underlying
> socket events. I understand that ZMQ does not attempt to promote accessing
> these events, in preference for building reliability measure such as
> heartbeating into the system architecture. However, I find that I need
> access to these events for my architecture. I have put together a zsockmon
> that I use for this and thought I'd share it, as it may be useful to others.
> A candidate CZMQ implementation for accessing socket events in a CZMQ
> manner...
> https://gist.github.com/claws/7188924
> I am in the process of building a prototype application framework that will
> hopefully replace an existing system that has been identified as problematic
> as it suffers from a rigid, brittle and static configuration file defined
> communications architecture.
> The goal is to make use of application services starting up on random tcp
> endpoints and for clients to make use of dynamic discovery. This approach
> works well, as demonstrated in the similar zbeacon and zyre examples.
> An example of the problem I encounter (where I find I need access to socket
> events) is when a service provider running a SUB socket is restarted
> (crashes, upgraded, etc) I need the attached PUB sockets to detect the
> disconnect, drop the socket and ask the discovery mechanism to resolve the
> service again as it will now (likely) be operating on a new endpoint.
> I'm open to architecture design changes if anyone has suggestions that can
> resolve this kind of problem without resorting to socket events? I guess it
> would involve adding another socket to these application to use for
> health/heartbeating.
> Regards,
> Chris
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Pieter Hintjens
CEO of iMatix.com
Founder of ZeroMQ community
blog: http://hintjens.com

More information about the zeromq-dev mailing list