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

[Goswin von Brederlow]

On Wed, Jul 02, 2014 at 06:09:04PM +0200, Pieter Hintjens wrote:
> I believe it's been mooted before, and ZMQ_STREAM sockets do this,
> sending null messages to signal when there's a new client connection
> and/or a disconnected client.
> 
> On Wed, Jul 2, 2014 at 2:08 PM, Goswin von Brederlow <goswin-v-b at web.de> wrote:
> > On Tue, Jul 01, 2014 at 06:23:41PM +0200, Pieter Hintjens wrote:
> >> On Tue, Jul 1, 2014 at 4:46 PM, Goswin von Brederlow <goswin-v-b at web.de> wrote:
> >>
> >> > 1) with ROUTER/DEALER I don't get a message when a subscriber
> >> > disconnects without unsubscribing.
> >> >
> >> > Eventualy the heartbeat will get it but that can take a long time and
> >> > a lot of messages can queue up inbetween for no good reason.
> >>
> >> There is no other way, in practice. Even if libzmq reports the TCP
> >> disconnect, there are cases where the network connection will block
> >> and die without reporting an error. You must eventually use
> >> heartbeats. You can tune these to a few seconds.
> >
> > But with tcp there is a way. And (X)PUB/(X)SUB do use it. I know it
> > isn't totaly reliable since it can't catch kernel or network crashes
> > in a timely fashion. But 99.999% of cases will properly close the tcp
> > socket.
> >
> > The goal is to catch the common case early while still handling the
> > exceptional one with heartbeats.
> >
> >> > So I tried using a monitor socket. But that only gives me the FD and
> >> > address of the receiving socket:
> >>
> >> No use IMO.
> >>
> >> > 2) with XPUB/XSUB the CURVE metadata seems to get lost
> >> >
> >> > zmq_msg_gets() always returns Null it seems. I think the problem is
> >> > that zmq::xpub_t::xread_activated just appends the message data to its
> >> > internal std::deque. A ROUTER socket on the other hand attaches the
> >> > pipe to its fair queue.
> >> >
> >> > Should this be rewritten to use a fair queue too?
> >>
> >> That would make sense, yes.
> >>
> >> -Pieter
> >
> > MfG
> >         Goswin

I can think of 3 ways to implement this (across all socket types):

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.

2) Include the identity in the DISCONNECT event on the monitor socket.
Again some flag would have to be there for backward compatibility as
it would increase the DISCONNECT event by one frame.

Since the identity is set only after the connection is established I
think this couldn't be used to announce identities as part of an
existing event, right?

3) Add 2 new monitoring events: IDENTITY_SET and IDENTITY_DISCONNECTED.

For this the event mask would act as compatibility flags. This would
probably be the cleanest solution.

MfG
	Goswin