I was asking about the plans for these kind of semantics in the future and your stance on them. That is, are you planning to do it in some future version or you're against such API calls for some reason? My rationale for inclusion of these calls is very simple: 0MQ sockets do have a lot of state and recreating this state could be hard. On the other hand, spending resources on maintaining a [raw] connection that is not needed doesn't look like a nice idea too. I can provide an example from our system: we've got several data feeds and several consumers, each of whom may connect to any number of data feeds at any point in the lifetime (we've got separate sockets that provide discovery servers for these data feeds). 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.
On Sat, Sep 25, 2010 at 12:04 PM, Pieter Hintjens <[email protected]> wrote: > Yes, there are no semantics to unkind or disconnect, only close the socket. > > -Pieter > > On 25 Sep 2010 04:24, "Joshua Foster" <[email protected]> wrote: > > Check out close: http://api.zeromq.org/zmq_close.html > > > > Joshua > > > > On Sep 24, 2010, at 6:38 PM, Alexey Ermakov wrote: > > > >> Hi, > >> > >> I might be missing something and it's probably been discussed already, > but I couldn't find much about unbind/disconnect calls. These calls are > unnecessary for normal sockets, but 0MQ sockets are completely different > things that live for much longer (because they automatically reconnect) and > may carry a lot of state (such as subscriptions in PUB/SUB) sockets, so the > lack of these calls seems rather strange. > >> Has there been a decision to not implement them because of some reasons, > or they've been left out due to time constraints and are on the roadmap for > some future release? > >> _______________________________________________ > >> 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 > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
