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

[Steven McCoy]

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.

http://tools.ietf.org/rfcmarkup?doc=3208#page-82

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.

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