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
