[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
remember.

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?

-Pieter


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