On Mon, Jul 20, 2015 at 08:43:55PM +0200, Pieter Hintjens wrote: > Hi Ricardo, > > Thanks for this analysis and proposal. In general we welcome patches > (pull requests).
I'd gladly prepare a PR to fix the issue but given that the solution is non-trivial without breaking the current API, I was asking for some advice on the matter of how to proceed. > On Mon, Jul 20, 2015 at 2:31 PM, Ricardo Catalinas Jiménez > <[email protected]> wrote: > > (a) Stop filtering in XSUB socket at all and rely on this in XPUB > > sockets. So that we modify the trie_t to not to have a refcnt field > > and xsub_t forwards all the (un)subscription messages it received. > > > > This is my preferred solution although it could break applications > > that subscribe multiple times to the same topic and expect to stop > > receiving messages only when they unsubscribe the same number of > > times. Although I'm not aware that this behavior is documented > > which could mean it isn't really a problem. I checked the docs again and no, solution (a) isn't possible as it breaks the contract described in the current API: ZMQ_UNSUBSCRIBE: "If the socket has several instances of the same filter attached the ZMQ_UNSUBSCRIBE option shall remove only one instance, leaving the rest in place and functional." That leave us in a position where we need to keep the reference counting in the XSUB side. The only solution I can think about includes this two modifications: 1. Don't filter repeated unsubscribe messages in XPUB but keep the reference counting to not to break the API: we are already not filtering subscribe messages, so the other half of the logic should be symmetrical. 2. Add another flag to zmq_setsockopt named ZMQ_XPUB_UNSUBSCRIBE_VERBOSE so that this should be enabled in the XPUB sockets used in proxies to not to filter repeated unsubscribe messages to make sure the reference counting works properly propagating always these upstream up to the producer application which won't use this flag in its XPUB socket. I don't like adding more flags to the API, but I cannot think of any other way to solve this right now. Suggestions are welcome. Best, /Ricardo _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
