Q:

ZeroMQ pipeline with return to initial client

The gist of what I'm trying to accomplish is to have a fan-out type of processing that will return a result to the initial client. 
Right now, it is set up as:
[REQ]-->[ROUTER|PUB]-->[SUB|PUSH]-->[PULL|???] 

I have it set up as PUB-SUB as the idea is that each SUB node will process a different part of a given manifest.   For certain manifests, all SUB nodes are hit.   For other manifests, maybe only a subset of the SUB nodes are hit.   Using the SUB allows me to implement it without creating a discrete decision point on which nodes to route to. 
I've got it to the point where I'm more or less able to bring the results together, but I have no idea how I'm supposed to return a result to the initial caller on the REQ without the caller binding a new socket at the client and then connecting to the socket.   Mistakenly, I figured that if I could get the address of the caller at the ROUTER, I could pass that info along and send a message back to the initial REQ. 
It seems that it should be possible and what I'm missing is perhaps some device coupled to the ROUTER? 
So is it possible to accomplish this and is there a better pattern for this without binding another socket at the caller? 

A:

The initial caller REQ expects its reply from ROUTER and cannot accept messages from anywhere else.  Therefore, a simple approach would be a broker with three endpoints:

ROUTERfor communication with client
PUB for sending message to all workers
PULL for getting in the results 

Routing within the broker would be:

ROUTER -> PUB
PULL -> aggregate_by_client_id() -> ROUTER

The from my point of view tricky part is hidden in aggregate_by_client_id(), which is necessary since you can send only answer to REQ.  Do you know how many results from workers to expect? 