[zeromq-dev] how to reliably wait for SUBscribers to connect before sending messages

Luca Boccassi luca.boccassi at gmail.com
Fri Jan 5 12:46:45 CET 2018

On Fri, 2018-01-05 at 12:33 +0100, Francesco wrote:
> Hi Luca,
> 2018-01-05 12:23 GMT+01:00 Luca Boccassi <luca.boccassi at gmail.com>:
> > On Fri, 2018-01-05 at 12:04 +0100, Francesco wrote:
> > > Question for zmq developers: would be possible to add a new event
> > > to
> > > the
> > > socket monitor interface that tells you when the SUB side has
> > > _really_
> > > connected and is for sure ready to receive messages?
> > 
> > Use XPUB - it will deliver the subscription message to the pub
> > socket.
> > 
> > You mean that I can avoid to sleep() if I use an XPUB socket
> > instead of
> PUB and do:
>  - zmq_bind(),
>  - zmq_msg_recv() (waiting to receive a 1byte message)
>  - zmq_msg_send()
> and the SUB socket will surely receive the same number of messages
> sent on
> the XPUB side?

Yes - the message will have the topic subscription after the 0/1
prefix, so not 1 byte.

> That would be a solution even if at my stage of development changing
> from
> PUB to XPUB may have side effects I cannot easily understand right
> now...

If you have a requirement to wait for subscriptions then xpub is the
right one. That's the only difference.

Although what you should really consider is that pub-sub is lossy by
design - your application-level protocol needs to be able to handle it
gracefully. Either by making data loss acceptable, or by having per-
message monotonically increasing uuids, and a re-sync side-channel
where client can request replays when they notice a missed message (gap
in the uuids). I believe this is mentioned in the zguide somewhere.

Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20180105/522e6787/attachment.sig>

More information about the zeromq-dev mailing list