Now let’s extend the REQ-REP pair with a ROUTER-DEALER proxy in the middle and see how this affects the reply envelope. This is the extended request-reply pattern we already saw in Chapter 2. We can, in fact, insert any number of proxy steps (Figure 3-2). The mechanics are the same.
Figure 3-2. Extended request-reply pattern
The proxy does this, in pseudo-code:
prepare context, frontend and backend sockets while true: poll on both sockets if frontend had input: read all frames from frontend send to backend if backend had input: read all frames from backend send to frontend
The ROUTER socket, unlike other sockets, tracks every connection it has, and tells the caller about these. The way it tells the caller is by sticking the connection identity in front of each message received. An identity, sometimes called an address, is just a binary string with no meaning except “this is a unique handle to the connection.” Then, when you send a message via a ROUTER socket, you first send an identity frame.
zmq_socket() man page
describes it thusly:
When receiving messages, a ZMQ_ROUTER socket shall prepend a message part containing the identity of the originating peer to the message before passing it to the application. Messages received are fair-queued from among all connected peers. When sending messages a ZMQ_ROUTER socket shall remove the first part of the message ...