[zeromq-dev] Various Majordomo protocol versions

Bob Eby ebyrob at gmail.com
Sun Mar 1 18:16:26 CET 2020


On Fri, Feb 28, 2020 at 1:13 PM Brett Viren <bv at bnl.gov> wrote:

> Hi Robert,
>
> Bob Eby <ebyrob at gmail.com> writes:
>
> > Brett Viren <brett.viren at gmail.com> wrote:
> >> And, what I *really* need is the Majordomo pattern but with
> >> CLIENT/SERVER for thread-safety.
> >
> > Pardon if I'm not quite following here, but isn't every ZeroMQ "message"
> an
> > atomic operation already?  In terms of a protocol library what more are
> you
> > expecting in providing thread safety?  Can't the rest be handled with a
> > minor wrapper if even that much is necessary?  (multi-thread apps
> probably
> > already have some mechanisms built in but I digress...)
>
> Below is my understanding which led me to this.  If any of it is wrong,
> please let me know as I'd rather stick with non-draft sockets in my
> application.
>   ...


Suffice to say, I'm not all that experienced, I've used REQ/REP with DEALER
per the cookbook examples, and I've noticed that when sending multipart
messages the reply processing never starts until the last message portion
is received by REP socket.  Not that this guarantees thread safety, but it
does imply even multi-part messages may be nearly atomic per message.

In any case, it seems clear the majordomo stuff is essentially "3rd party"
and not mainline ZeroMQ.  I was almost going to suggest using 1 single
thread per DEALER (possibly not necessary for SERVER socket if each DEALER
thread has unique ZMQ source address then SERVER can see that and behave
accordingly per message).

In my own application, I have only a single REQ thread per client process
and a DEALER/ROUTER forwards the source address, so the only real
multi-thread part is the server REP sockets that only process a single
REQ/REP cycle at a time each which just respondes to the correct calling
REQ socket address.

It really sounds like you've got a handle on it, just be sure to do some
testing to be sure the implementation matches your expectations.  (I
certainly did this and is how I saw the multipart behavior above)

That's about all I know.

Good Luck,
Robert E.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20200301/b6780ae8/attachment.htm>


More information about the zeromq-dev mailing list