On Fri, Feb 28, 2020 at 1:13 PM Brett Viren <[email protected]> wrote: > Hi Robert, > > Bob Eby <[email protected]> writes: > > > Brett Viren <[email protected]> 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 [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
