[zeromq-dev] Notes from a hackathon

Thomas Rodgers rodgert at twrodgers.com
Mon Feb 2 14:29:25 CET 2015

> - deprecate REQ and REP

It would seem, given their limited utility, that marking these DEPRECATED
in the next version of libzmq would be an easy step to take.

It seems to me that in order to remove multi-part messages and introduce
new socket types (e.g. SERVER/CLIENT) that would
necessitate a revision of the wire protocol. If we are going to do that, it
might be worth considering per-message
metadata -

* There have been at least a few questions/requests in this direction, the
wire protocol doesn't support it.
* The metadata would have the same basic wire format as connection
metadata, and read as part of a single message.
* It might serve to eliminate some uses of multi-part messages without
resorting to some form of in-message framing.

On Mon, Feb 2, 2015 at 3:23 AM, Pieter Hintjens <ph at imatix.com> wrote:

> Hi folks,
> We had an interesting pre-FOSDEM hackathon on Thursday and Friday, in
> Brussels.
> One of the threads that came out, thanks mainly to Doron Somech
> (NetMQ) was a strategy for simplifying ZeroMQ. This started as a
> discussion of Nanomsg's dropping of multipart messages.
> Overall, multipart messages add a lot of complexity and confusion to
> the library and bindings. In case we forget:
> - frame vs, message vs. part
> - routing id frames
> - request-reply envelopes
> - router sockets
> - identities
> Multipart messages are the main reason we can't make threadsafe sockets.
> So, we're going to experiment with shifting ZeroMQ (libzmq, NetMQ,
> CZMQ, and other bindings) in this direction:
> - deprecate multipart messages from the API - when we need framing, we
> can use zproto
> - deprecate ROUTER and DEALER and slowly replace with SERVER / CLIENT
> sockets that refuse multipart data
> - deprecate REQ and REP
> - SERVER has get/set routing ID on message
> - routing ID is an integer
> - routing ID cannot be set by peer, so we deprecate ZMQ_IDENTITY
> - start to aim for threadsafe sockets
> - deprecate the ability to build request-reply chains
> ...
> This is not a roadmap, nor is this a proposal, it's just a realization
> by several of us that multipart messages create complexity, which we
> dislike, and which causes cost and irritation.
> Cheers
> Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150202/41502d2f/attachment.htm>

More information about the zeromq-dev mailing list