When using ZeroMQ Socket, Can I send() from one thread and recv() from another to the same socket?

Question

I have find a question! before, but I still don't know how to do it, if i need to build The Asynchronous Client/Server by using ROUTER to DEALER socket.

Before using zeromq, when i need to build a async server, i will separate the socket's read part and write part.

A [dispatch] worker will epoll_wait socket's read event and launch [worker] thread to do some work according to the msg,

Finally, a .send() operation will be triggered in some different thread for the same socket.

Read and send can be separated in two different thread.

Recv and Send for one socket in 2 different thread

Is it possible ( allowed ) by using zeromq socket?

Actually I search some mail-list and get negative answer.

Then I am wondering how to deal with this scenario?

If only one thread could be used for a socket, how to improve the whole server's parallelism degree and throughput?

Answer 1

ZeroMQ evangelism promotes "Zero sharing == Do not share anything*"

One shall read it do not share socket ( more exactly a-ZMQ-socket access-point-object ), so right, you shall not design your code to "share" any socket among more than one threads.

That does not mean that two different threads or distributed processes cannot listen/speak to each other via a single ZMQ-socket, that was setup between them ( one .bind()-s, the other(s) .connect() ).

So your [ROUTER]-<__behavioralArchetypePRIMITIVE_> can .bind() it's output into the same ZMQ-socket object, that is published to get .connect()-ed on the opposite end by the [DEALER]-<__behavioralArchetypePRIMITIVE_> ( as in Fig. 27 Extended REQ / ROUTER | DEALER / REP Pattern) and get the job done.

*) Nota bene:

There is a principal exception to this Zero sharing rule, where a ZMQ Context instance may be intentionally shared among some localhost threads.

Answer 2

What problem are you trying to solve by splitting the send and receive actions of the socket into two different threads? Is it blocking? Because your single thread need not block while waiting for a response, you'll just have to use polling to continue processing.

Is it that you want some work done in some separate thread based on the response? If so, open up an IPC socket from one thread to the other and send the work that way.

"ZMQ Sockets" are not normal sockets that you're used to working with, they're more "socket-like things" that give you certain super powers, but you have to trade off the low level nuts and bolts in favor of this abstraction. So, no, you can't split up a single socket between multiple threads, you'll have to find some other way (using ZMQ, it's good for this sort of thing, or not) to communicate between your threads.

There are many viable methods to do this, and the one you choose would be determined by the particulars of your use case.

Answer 3

Sharing sockets between threads definitely fails, as the zmq guide clearly states.

I kind of implemented something like this for an application recently. A thread receives messages and delivers them through an INPROC socket to a thread which processes them. The reason is that I can still receive messages while the other thread is still working on something (I work with the API of an industrial system). I oriented myself on the multi-threaded server example. I highly recommend looking at it. My approach is the other way around (my "main" method is the worker routine and the separate thread receives the messages), but that doesn't matter.