[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