Let's have a look at the following code snippet from our worker code:
// Let's initialize a socket to receive messages.
void* receiver = zmq_socket(context, ZMQ_PULL);
The ZMQ_PULL socket
When we want to retrieve data from upstream to nodes, we use ZMQ_PULL . The
ZMQ_PULL type sockets are used to receive messages from upstream nodes in the
pipeline. As we have said earlier, this process is done with fair-queue scheduling.
zmq_send(3) cannot be used in place of ZMQ_PULL .
The ZMQ_PUSH socket
When we want to communicate downstream with nodes, we use ZMQ_PUSH .
The ZMQ_PUSH type sockets are used to send messages to downstream nodes
in the pipeline.
ZMQ_PUSH never discards messages. If a high watermark is reached for downstream
nodes, or if there are no downstream nodes available, all messages sent with zmq_
send(3) are blocked until there is an available downstream node to receive messages.
Getting ZeroMQ context
You must have realized by now that all examples we have done so far start with zmq_
ctx_new(3) . ZeroMQ applications always start with creating a context. All sockets
are put inside a single process using the context, which acts as in-process sockets since
they are the fastest way to connect threads in a single process. ZeroMQ context is
thread safe and you may share it with multiple threads.
If ZeroMQ context cannot be created, it returns NULL .
Even though it is possible to create multiple contexts, which would be considered
as separate ZeroMQ applications, it is a better idea to create one ZeroMQ context
rather than multiple ones.