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 <[email protected]> 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 > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > -- - Pieter Hintjens CEO of iMatix.com Founder of ZeroMQ community blog: http://hintjens.com _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
