[zeromq-dev] Various Majordomo protocol versions

SIMON BABY simonkbaby at gmail.com
Fri Mar 13 06:18:24 CET 2020

can someone comment on the below error I am getting oon ubuntu.

g++ -std=c++11 -fPIC -Wall -Wextra -fmessage-length=0 -pthread -O2
-Iinclude -MMD -MP -c src/zipcpp.cpp -o build/src/zipcpp.cpp.o

src/zipcpp.cpp: In function ‘bool zipc::sockPoll(zmq::socket_t*, int)’:

*src/zipcpp.cpp:125:53: error: cannot convert ‘zmq::socket_t’ to ‘void*’ in

*     pollitem_t pollItem = { *sock, 0, ZMQ_POLLIN, 0 };*

*                                                     ^*

src/zipcpp.cpp: In static member function ‘static std::vector<long unsigned
int> zipc::Endpoint::pollEndpoints(const EndpointList&, int)’:

*src/zipcpp.cpp:380:69: error: cannot convert ‘zmq::socket_t’ to ‘void*’ in

*         pollitem_t pollItem = { *epIt->get().sock, 0, ZMQ_POLLIN, 0 };
// no constructor for pollitem_t*

sudo apt-cache search libzmq3-dev

libzmq3-dev - lightweight messaging kernel (development files)



On Sun, Mar 1, 2020 at 9:19 AM Bob Eby <ebyrob at gmail.com> wrote:

> 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.
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20200312/f49c5af3/attachment.htm>

More information about the zeromq-dev mailing list