[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
initialization*
* 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
initialization*
* 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)
*Rgds*
*Simon*
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