Handling removal of topics isn't a problem — I already do that and it works just fine. My concern with the lack of disconnect() call is that 1) 0MQ may spend resources sustaining this connection or endlessly reconnecting to it (in case the server has been shutdown) and 2) in the current model, SUB sockets still receive everything sent to the PUB socket so I'll needlessly waste traffic.
On Mon, Sep 27, 2010 at 6:17 PM, Robin Palotai <[email protected]>wrote: > What way do your feeding PUBs use topic? > 1, If each PUB has a separate topic, then unsubscribing can easily be done > on a per-PUB basis. > 2, If each PUB uses a range of (common) topics, then the topic may be > postfixed with a unique key corresponding that publisher. Then the SUB would > selectively subscribe to each sometopic1.somepub1, sometopic1.somepub2, ..., > and so could selectively unsubscribe also. (If you use multi-level topics, > then prefixing the unique key may also be possible, however it breaks > compatibility with existing clients maybe). > > What do you think? > > BR, > Robin > > 2010.09.27. 15:59 keltezéssel, Alexey Ermakov írta: > > No, I want an api to add/remove connections/bindings. > Right now it is possible to dynamically add new connections to the SUB > socket, but impossible to remove them (I don't think closing the socket, > recreating it, connecting to all urls minus one and restoring subscriptions > is a feasible solution). > > On Mon, Sep 27, 2010 at 2:09 PM, Steven McCoy <[email protected]>wrote: > >> On 27 September 2010 17:58, Alexey Ermakov <[email protected]> wrote: >> >>> At the application level all data is consumed by one entity, so it makes >>> sense to have one SUB socket that dynamically connects to multiple PUB >>> sockets. However, when a connection becomes unneeded I cannot simply call >>> zmq_disconnect(), I have to close the socket, recreate it, restore the >>> connections that are needed to be alive and then restore the subscriptions. >>> This 1) sounds like too much work for a simple operation and 2) means I'll >>> have a gap in the received data. >>> >>> >> I'm still not sure of what you are asking, is the ZMQ_UNSUBSCRIBE option >> insufficient here? You wish a batch subscription API to bring up and down >> 1,000's of topics? >> >> An alternative reading suggests you want to keep the subscriptions but >> have an API to ignore the content, so why not just implement this at the >> application layer? >> >> -- >> Steve-o >> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> > > _______________________________________________ > zeromq-dev mailing > [email protected]http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
