[zeromq-dev] RFC: PPPP - Paranoid Pirate Publishing Protocol

[Goswin von Brederlow]

On Thu, Jul 03, 2014 at 11:50:44AM +0200, Pieter Hintjens wrote:
> 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

I've been thinking some more about this. Say you have the following
topology with a proxy:

SUB 1 --------------\
SUB 2 ---------------= PUB
SUB 3 --= XPUB-XSUB /
SUB 4 -/

When SUB 1 subscribes to something then PUB gets a subscription event.
When SUB 3 subscribes to something then XPUB gets a subscription event
and then sends out a subscription on XSUB so PUB gets a subscription
event too. So applications need to be able to generate and send event
messages over the network. It's not just events generated by ZMQ
internally as a reaction to a change in the sockets state.


Now lets look at a more general case of what that would mean for other
sockets and "connected" events in general:

REQ 1 ------------------\
REQ 2 -------------------= ROUTER2
REQ 3 --= ROUTER-DEALER /
REQ 4 -/

When REQ 1 connects to ROUTER2 it gets a "connected" event with one
data frame containing the identity of REQ 1. When REQ 3 connects to
ROUTER it gets a "connected" event with one data frame containing the
identity of REQ 2. So far that is all internal in zmq. But the proxy
should then forward that event to the DEALER socket so the ROUTER2
gets a ""connected" event with two data frames containing the identity
of DEALER and REQ 3 respectively.

That way ROUTER2 then knows that REQ 3 has connected and is reachable
via the DEALER.

Of course wether the proxy even gets events at all and wether it
forwards those is left to the application. But sometimes you want/need
that.

Does that make sense?

MfG
	Goswin