[zeromq-dev] Notes from a hackathon

Brian Knox bknox at digitalocean.com
Wed Feb 4 12:37:22 CET 2015


After catching up on this thread, I feel like at least three problems are
being conflated into one problem.  I'll state what I see being discussed
from my perspective:

1. "Using multi part messages as a way to route to clients from a router
socket is overly complicated and not how new users expect things to work"

2. "Using multi part messages for message serialization is costly, and
potentially confusing to others."

3. "ZeroMQ sockets are not thread safe."

While on an implementation level these three problems may be related, on a
conceptual level I don't see them as related.  I may agree with some of
these problem statements and not others.

For me, my first priority is to always have the ability to get back a nice
agnostic blob of bytes from ZeroMQ.   This makes it easy to make ZeroMQ
socket use compatible with standard io interfaces in Go.  Structure for
what is contained in those bytes is a concern of a different layer.
Sometimes I use zproto for this (which I like), and other times I don't.

As a demonstration that the problems are different problems, I solved #1
for myself in goczmq without addressing anything else.

I would assert some of the confusion in this discussion is that we're
talking about multiple problem statements at the same time.

Cheers - and it was great meeting people this week!

Brian




On Wed, Feb 4, 2015 at 12:50 AM, Pieter Hintjens <ph at imatix.com> wrote:

> Ironically, in my testing of high message rate), allowing multipart
> creates significant costs. Multipart is just one way of getting
> zero-copy, and even then only works on writing, not reading.
>
> For high performance brokers like Malamute I'd *really* like to be
> moving blobs around instead of lists of blobs.
>
>
> On Wed, Feb 4, 2015 at 12:41 AM, Gregg Irwin <gregg at pointillistic.com>
> wrote:
> > M> Perhaps it is because I spend my days in a higher level language
> > M> like Python, but zproto is not an attractive option.
> >
> > Same here. I will read in detail about it shortly, but it may not make
> > it into my toolbox as a multipart replacement. Multipart looked very
> > cool when I found 0MQ, but I've ended up not using it much. I'm not
> > doing high performance stuff though. Simplicity and ease of use are
> > tops on my list.
> >
> > -- Gregg
> >
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> 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/20150204/87754a4e/attachment.htm>


More information about the zeromq-dev mailing list