On Thu, Jul 3, 2014 at 10:35 AM, Goswin von Brederlow <[email protected]> wrote:
> I can think of 3 ways to implement this (across all socket types): Do we want this across all socket types? For ROUTER, certainly. Right now we're hacking this using ZMQ_ROUTER_PROBE. For other socket types, it seems to break the abstraction. > 1) Sending a message with identity (or command?) flag set containing > the identity and wether it is a connect or disconnect as frames. For > backwards compatibility that should only be send when a socket option > is set, default to off. Yes. > 2) Include the identity in the DISCONNECT event on the monitor socket. > 3) Add 2 new monitoring events: IDENTITY_SET and IDENTITY_DISCONNECTED. This was the original argument against adding monitoring at all, that it would be abused for topology purposes. Once you start to give the application knowledge of the topology, you break the ZeroMQ abstraction and you kill scalability. (This was Sustrik's argument, and I mostly accept it.) More pragmatically, you *cannot* safely use monitoring for such things. Monitoring events are asynch and processed out of band. You cannot sanely synchronize monitoring events with message flow, except by injecting them into the message flow itself, and then you get option (1). The simplest backwards compatible solution would be: 1. use a socket option to enable connect/disconnect events 2. deliver these events as messages, on the socket 3. use a message format that is easy to filter, e.g. size=2 4. use a message flag, ZMQ_EVENT, via zmq_msg_get 5. enumerate the events, 1=CONNECT, 2=DISCONNECT, etc. 6. optionally, allow more parts to follow, depending on the event type. This could be implemented for all socket types. There are other events we could conceivably add, and we could fix XPUB to use events instead of its magic subscribe/unsubscribe messages. An event interface is much cleaner than monitoring. It still breaks the scalability abstractions, except for ROUTER where it's a good fit. -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
