[zeromq-dev] Knowing number of peers in of publisher

Steven McCoy steven.mccoy at miru.hk
Thu Aug 5 02:30:59 CEST 2010

On 4 August 2010 17:58, Bertrand Nouvel <bertrand.nouvel at gmail.com> wrote:

> 2010/8/4 Steven McCoy <steven.mccoy at miru.hk>
> On 4 August 2010 13:09, Bertrand Nouvel <bertrand.nouvel at gmail.com> wrote:
>>> Hi,
>>> I am quite new with 0MQ. PGM seems really nice.
>>> I would have one question, I did not find reply in the FAQ/docs.
>>> Does 0MQ provide a way to know the number of subscriber to a publisher ?
>>> It would be really convenient in some case to start a broadcast when the
>>> correct number
>>> of peers have connected to the publisher.
>> At the protocol level, if the peers are functioning bi-directionally like
>> the TIB it would be possible to find an estimate of the number of receivers.
>>  However much like RV version 5 versions SASS 3 you really need to implement
>> subscription logic above PGM, for market data this is usually required for
>> auditing and entitlements.
>> At the base level ZeroMQ strictly uses PGM as a uni-directional transport;
>> the PGM usage does have an upstream for re-transmission requests but is
>> technically possible to disable it completely and so you would not receive a
>> single packet from receivers meaning that you must implement the
>> subscription logic at the higher level.
>> --
>> Steve-o
> As there was the "recovery_interval" I was somehow thinking that this
> information might have been available.. But it is of course more efficient
> to cast data without
> having to wait explicitely for ack.
There is an optional feature of the PGM protocol to implement polls, one of
the polls is a simple population count to determine optimum back off and
recovery parameters.


This is half implemented in OpenPGM 5, not completed as there is a
performance issue when handling multiple polls.  Each poll requires state
and each peer might institute a poll, it's really not a good idea to be
allocating extra state blocks per packet for every poll and then becomes a
DoS source.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100805/96157f10/attachment.htm>

More information about the zeromq-dev mailing list