[zeromq-dev] Various Majordomo protocol versions

[Brett Viren]

Hi John,

On Fri, Feb 28, 2020 at 7:05 PM John Jefferies <j.jefferies at ntlworld.com>
wrote:

>
> If you are using CZMQ, you can use zmsg_encode() and zmsg_decode() to
> serialise multi-part messages when using them with CLIENT/SERVER.
> Everything else in existing examples can remain the same. Obviously a bit
> less efficient, but hopefully that's ok for you.
>

Funny you should say that....  After indeed making a hash of freshening the
majordomo package with GSL I abandoned that and took the exact tack you are
suggesting.

Here's some details of where I'm at and going in case anyone spots any red
flags:

First, I tried a DIY encode/decode but then remembered from a past project
using CZMQ that it provided these codec methods you suggest.  My naive
approach was simply prefixing each frame with a 4 byte size.  OTOH, CZMQ's
codec is a little bit fancier.  It uses a 1 byte count for small frames and
5 byte count when the 1 byte overflows.  This seems technically better to
reduce overhead for small frames and, in any case, avoiding divergence is a
good thing so I discarded my simple packing scheme.

Now, this current project is based on cppzmq and so I've added a
CZMQ-compatible encode/decode to zmq_addon.hpp as methods in the
multipart_t class.  Off topic, but I've also added a CZMQ-style actor as a
new cppzmq/zmq_actor.hpp as I'll need this pattern for other parts of my
system.  I am in the process of adding these changes and some tests and
docs to cppzmq and will soon make a PR for consideration.

I have started a project called "generaldomo" which allows a
runtime-configurable choice to use ROUTER (7/MDP) or SERVER (packed-7/MDP)
sockets in the broker.  A working prototype exists in Python and with the
above codec looking good in cppzmq, the C/C++ version is following.  The
broker allows either type of socket by wrapping send()/recv() with a switch
on the socket type.  If SERVER, then the codec is used.  If ROUTER, then
the address envelope stack is removed.  The resulting message payload is
then identical in the two cases: a multipart_t.  The "routing ID" is also
generalized.  For SERVER it's the uint32 from routing_id() and for ROUTER
it's the address envelope stack carried around on the heap as a
multipart_t* (these differences soaked up in a std::variant).  The rest of
the "guts" of the broker can then be essentially what is in the zguide
examples but converted to use cppzmq.   I'm also factoring the broker a bit
to make it able to integrate into the cppzmq actor I cooked up.
Specifically, I need the broker to expose the inner part of its main loop
so I can have the actor function poll both the actor pipe and the broker
socket.  The needed factoring looks straight-forward.

Thanks for the ongoing guidance,
-Brett.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20200229/e5982cc5/attachment.htm>