[zeromq-dev] client/server sockets -- stability

Bill Torpey wallstprog at gmail.com
Mon Oct 16 20:31:25 CEST 2017

Thanks Luca!

From the thread it sounds like the consensus is that you can have thread-safe or multi-part, but not both, and that client/server sockets will be in addition to router/dealer sockets, which will not be deprecated going forward.  Is that correct?

If that’s the case, is it safe to assume that (a) client/server socket types will continue to be supported going forward, and (b) the essential property (block on mute) will remain the same?



> On Oct 16, 2017, at 2:00 PM, Luca Boccassi <luca.boccassi at gmail.com> wrote:
> On Mon, 2017-10-16 at 11:53 -0400, Bill Torpey wrote:
>> Hi All:
>> Without going into too much detail (I’ll save that for another post
>> when I’ve gotten all my ducks in a row), it looks like I’ve found a
>> solution to the problems I’ve been having using different socket
>> types to do inter-thread synchronization, which ends up being
>> client/server sockets over inproc.  (Which ironically has nothing to
>> do with their thread-safety, but everything to do with the fact that
>> sends will block until the message can be queued/delivered).
>> I notice the disclaimer that these are drafts and subject to change,
>> etc., so my question is whether there is any expectation around when
>> these socket types will be declared “stable”?  
>> Can anyone shed any light on the process needed to move these to
>> stable status, and/or what the timeframe might be?
>> Many thanks in advance for any help!
>> Regards,
>> Bill Torpey
> Documentation is missing, and also there was still recently some
> brainstorming on how to do something akin to multipart in the new
> sockets, which might require API breakages:
> https://github.com/zeromq/libzmq/issues/2699
> -- 
> Kind regards,
> Luca Boccassi_______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev

More information about the zeromq-dev mailing list