Hi John, On Fri, Feb 28, 2020 at 7:05 PM John Jefferies <[email protected]> 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.
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
