[zeromq-dev] subscribe/unsubscribe refcounting behaviour

Matt Weinstein matt_weinstein at yahoo.com
Wed Aug 18 12:35:50 CEST 2010


On Aug 18, 2010, at 2:19 AM, Martin Sustrik wrote:

> Jon,
>
>> 2) are they happy with it?
>
> It's needed to be able to aggregate subscriptions from mutliple  
> sources.
> Currently, the subscriptions are not forwarded upstream so both
> refcounting and idempotency would work. Once the subscription  
> forwarding
> is implemented, subscription idempotency would allow one subscriber to
> unsubscribe another one.
>

Why not use a UUID (identity) for each subscriber, and maintain per- 
subscriber idempotency? (is that a word? :-) )  Then you know what was  
subscribed to, and:

- When transport is multicast, the publisher sends the union of the  
active subscriptions
- When transport is point to point, the publisher sends just the  
active subscriptions for that subscriber

There are combinations where you have multiple p-p subscribers plus  
multicast.  It depends on how the subscriber "connects" the  
infrastructure.
.
Sounds like the simplest approach is for pub and sub sockets to mirror  
REQ/XREQ REP/XREP (use identity prefixes) which might make for some  
interesting mixes :-)

Then there are devices, e.g. a subscription proxy (forwarder from  
mcast over tcp/udp to mcast) will look at the subs identities on the  
way through.

etc.

I'm not even going to mention that you need to JIT the filter :-)

Best,
Matt

> Martin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev




More information about the zeromq-dev mailing list